The Coded Self

Perfect is the Enemy of the Good

2018-11-13T00:00:00+00:00

How the Wrong Architecture Can Cripple Development

A couple of years ago, I was working on a side project with a few friends. We thought that it would be the next big thing. We put our collective best efforts into it; I worked long, hard hours fleshing out the scaffolding of the perfect architecture. Little did I know that my effort would doom the project to join the abyss of failed projects as quickly as it had begun.

We had the best tools

Since this was The Next Big Thing™, we used everything at our disposal.

RxSwift for reactive programming
VIPER for our architecture pattern
Swinject for dependency injection
Cuckoo for mocking
Flow Operations for managing navigation

The Flow Operations were a particularly interesting concept, inspired by the Advanced NSOperations session from WWDC 2015. We used Flow Operations to manage navigation in the app. For instance, if you wanted to register a new user, you’d invoke a RegisterFlowOperation.

A FlowOperation was a subclass of Operation:

class FlowOperation: Operation

The Operation class represents the code and data for a task of your choosing. It also handles concurrency and dependencies. So, our Flow Operations represented the task of flowing from one screen to another in an app.

Operations can be dependent on each other - for instance, the EditProfileFlowOperation is dependent on the SignInFlowOperation. If you’ve already signed in, you can edit your profile, but if you haven’t, then you’ll be directed to sign in if you invoke the EditProfileFlowOperation.

How does it work?

There was a lot of hidden complexity in the Flow Operation system, and some trickiness that you wouldn’t notice until you started using it. I’ll briefly go over some of the code.

You could sell products in this app we were building. This is how you’d start the Sell Flow:

private func startSellFlow() {
  DispatchQueue.global().async { [navController = navController] in
    let flow = SellFlowOperation(navigationController: navController)
    flow.beginFlow()
    flow.waitUntilFinished()
  }
}

You create the flow operation, call beginFlow to navigate to the first screen, and then waitUntilFinished to prevent other flows from executing until this one is done.

But, don’t forget to put it on a background queue, or the app will hang. Also, don’t forget to call waitUntilFinished, or nothing interesting will happen at all. If another flow was already executing, yours wouldn’t run until that one finished. I shudder when I think back on the hours of debugging issues like this. 💀

A flow can have one or more ViewControllers to display in succession. How? With a bunch of complicated RxSwift code, of course.

func present(viewControllers: Observable<UIViewController>,
             finishWhenDone: Bool = false) {
  viewControllers.observeOn(MainScheduler.instance)
    .subscribe { [weak self] event in
      if case .next(let viewController) = event {
        self?.pushViewController(viewController)
      } else if finishWhenDone {
        self?.finish()
      }
    }.addDisposableTo(disposeBag)
}

It subscribes to an RxSwift Observable of UIViewControllers that come from the Presenter portion of the VIPER architecture. When a new ViewController is received from the FlowAction, it’s pushed onto the navigation stack. When there are no more ViewControllers, the FlowAction finishes (if finishWhenDone is true).

A Router object ➡️ invokes the Flow Operation ➡️ which gets View Controllers from a Presenter ➡️ and then pushes them onto the navigation stack.

Technically…

It’s a great system. It’s a complex, well-thought out architecture. Dependencies are managed elegantly and each part of the system has its own single responsibility.

Sounds good, right?

In practice…

It’s a mess. The architecture is extremely hard to use. You need to remember to:

Invoke the FlowOperation on the background thread, or you’ll cause a deadlock.
Call beginFlow to start the flow, or nothing will happen.
Supply ViewControllers from a Presenter or no new screens will display.
Call finish when you’re done to allow the next flow to start.
Don’t create dependency cycles between flows or the app will crash.

Complex architectures create complex problems. Building the right architecture for the right app is extremely important. I’m not advocating for spaghetti code. But when you build unnecessary complexity into an architecture like the one I just described, you’re asking for trouble.

Developers follow the path of least resistance. A hard to use architecture causes a lot of resistance. When no one can figure out how to put a simple ViewController on the screen, they’ll just opt for MVC instead. If you want your team using something other than Massive View Controllers, you need to provide something that’s easy to use, or it won’t be used at all.

With a hard-to-use system like the Flow Operations, it’s probably better that they follow the path of least resistance and default to MVC anyways. A system with so many ‘gotchas’ makes it extremely easy to write buggy code. Remember the background thread. Remember to avoid dependency cycles. The more tricky bits you need to remember, the more likely you are to create bugs and spend more time in debugging than building actual features.

A better approach

What could have changed in the Flow Operation architecture that might have led the project to better success?

Easier

Your architecture shouldn’t make life harder. If you want things to be hard, program in assembly. I’d much rather build my apps in a way that’s easy to build now, and easy to maintain later.

Enabler

The structure you have in place is not meant to be a barrier that keeps you from moving forward. Following VIPER or MVVM provides you with some scaffolding, but building something new shouldn’t be a complicated process that’s prone to errors. These architectural patterns are there to make development faster, in the long run.

When you have to keep a list of tricky problems in your head just to push a new ViewController onto the screen, then something’s gone wrong.

Don’t make me think

How easy is the system to understand? How easy was it to write? Will you be able to comprehend things 6 months from now? What about a new developer on the team: will they be able to ramp up without too many headaches in the process?

This is why I’ve fallen out of love with frameworks like RxSwift. It makes code hard to understand, and harder for team members that are less versed in the library. I love the benefits of reactive programming, but I’d rather take a simpler approach such as using property observers.

Getting there

There are a few things that I like to keep in mind when building an architecture. This works for scaffolding a project, building a class interface, or choosing third-party frameworks.

The right tool for the job

Complexity has its time and its place. Techniques that flourish in a large team of ten or more developers aren’t necessarily the right approach for your side projects. A complicated architecture shouldn’t be the starting point - add in the extra structure when your team grows and your needs evolve.

Rule of Three

Preventing code duplication seems like the #1 rule of clean programming. While removing code duplication is a commendable goal, don’t do it at the cost of creating an incorrect abstraction. When you’re looking at duplicated code, do the two pieces in question share a similar purpose? Or is their similarity merely coincidental?

Code duplication is bad. Creating leaky and incorrect abstractions is worse. They will mutate your code base into an abstract mess that requires a lexicon to make sense of.

YAGNI

You Ain’t Gonna Need It. For every possible future scenario that you can think of, 90% of them won’t happen. Don’t spend your time preparing for the possibility that a project manager might have a change of heart six months down the line.

Rather write clean, flexible code that can adapt to change. Write code that’s well tested and easy to change when the time comes. When a change of plans presents itself, you’ll be ready. But if you try and prepare for every possible future outcome? YAGNI.

The result

The unnecessary complication that I introduced to the side project mentioned earlier made development a pain. It was hard to build, and hard to use. The other developers on the project battled against the Flow Operations. RxSwift was a huge learning barrier for those that didn’t know it. And, for a small app and team like ours, VIPER was most likely overkill.

If, instead, we followed the principles mentioned in this post, we could have built something that was easy to understand. The less you have to think when figuring out how to use it, the better. It should be easy to use. An enabler to your programming, not a barrier.

The system should be only as complex as it needs to be to solve the problem at hand. If the problem changes, the complexity of the system can change to follow suit.

Do you have any horror stories from failed projects? Do you have any thoughts to share on this advice, or some of your own? Please leave it in the comments below!

UI Testing the Clean Way

2018-10-23T00:00:00+00:00

I write software, and sometimes I write bugs. But, when I do, I catch them early with testing.

I do manual tests before I commit, I write unit tests as I write my code. Lately, I’ve also been getting into writing UI tests.

One critique of UI testing is how messy and brittle it can be. Building the tests can be complicated. You might spend hours on a test just for a design to change that breaks the test and ruins all your hard work.

So, I want to tell you about some problems you might face in keeping your UI tests clean and readable, and how we can leverage Swift for this endeavour.

I’ll walk you through my approach to UI testing with everyone’s favorite example project - a To-Do list app. I know, boring, right? Well, it works perfectly for the examples we’ll be looking at, so…

You can download the example project here. It’s a simple app that allows us to create, edit, and delete a to-do.

Just press record

UI testing in Xcode is easy. Click inside the body of an empty UI test, click the Record button, and you’re up and running.

Let’s start off by recording a UI test to add a new to-do.

That was easy! And it sure did create a lot of code. That must be good, right?

func testExample() {
  
  let app = XCUIApplication()
  app.navigationBars["Todo List"].buttons["Add"].tap()
  
  let textField = app.otherElements.containing(.navigationBar, identifier:"New Todo")
    .children(matching: .other).element.children(matching: .other).element
    .children(matching: .other).element.children(matching: .textField).element

  textField.tap()
  textField.tap()
  
  let datePickersQuery = app.datePickers
  datePickersQuery.pickerWheels["October"]/*@START_MENU_TOKEN@*/.press(forDuration: 0.6);/*[[".tap()",".press(forDuration: 0.6);"],[[[-1,1],[-1,0]]],[0]]@END_MENU_TOKEN@*/
  datePickersQuery.pickerWheels["9"]/*@START_MENU_TOKEN@*/.press(forDuration: 0.5);/*[[".tap()",".press(forDuration: 0.5);"],[[[-1,1],[-1,0]]],[0]]@END_MENU_TOKEN@*/
  app.buttons["Done"].tap()
  
}

I’ll be honest, most of that is unreadable to me. Run the test, and you’ll see it doesn’t work, either. It completely missed the name of the to-do that we typed in, and the interaction with the date pickers doesn’t work either.

It’s clear that this approach won’t work for a large suite of UI tests. It’s a good learning experience to figure out what XCTest has to offer, but code like that shouldn’t be part of your code base.

Not as easy as we thought

There are clearly some problems with the recording approach to UI testing.

Complicated setup

Each of your tests will start on the main screen of your app. What if you want to test the editing of a to-do? Your test will start by opening a to-do, tapping the Edit button, and then proceed to the actual meat of the test. What if you need to sign in with a particular username and password? Each of your tests will need to do that, as well.

Duplicated code

There’s no code reuse when recording your tests. You can’t build any meaningful abstractions, or create helper functions that make the code easier to maintain and understand.

Hard to read

With lines like this in your code base:

let textField = app.otherElements.containing(.navigationBar, identifier:"New Todo")
      .children(matching: .other).element.children(matching: .other)
      .element.children(matching: .other).element.children(matching: .textField)
      .element

You won’t be able to figure out what’s going on in your tests a month from now. Enough said.

A better approach

There are many ways to improve the code that we got from recording a test, but since we’re using Swift, why not make use of protocol-oriented programming?

We’ll attempt to tackle the three problems of setup, reusability, and readability by using three families of protocols.

-Starting for setup

Remember the example of tests that start on the Edit screen of our to-do app, or a test that needs the user to be signed in?

When we need to specify where the test should start, we’ll create a -Starting protocol to carry that setup code. For instance, EditScreenStarting. By conforming to this protocol, we declare that a particular test case starts on the Edit screen. Anyone looking at the protocol conformances of the test case knows exactly what screen will be tested.

-Interacting for reusability

Recording your tests can spit out some complicated code that you’d need to copy-paste everywhere you want to perform the same action.

If we want to tap on a to-do named Buy Groceries, we’ll need to do something like this:

XCUIApplication().cells
  .containing(.staticText, identifier: "Buy Groceries")
  .firstMatch
  .tap()

It requires knowledge that the list of to-dos is a table view with cells that contain a label with the title. It’s not that complicated, but if the structure of your app changes and you have this code copy-pasted throughout your test suite, you’re gonna have a bad time.

Instead, we’ll wrap that into a protocol called TodoListInteracting later on. Any test case that is concerned with manipulating to-do list items will have to make its intention clear by conforming to TodoListInteracting.

-Verifying for readability

Tapping on the Plus button in the navigation bar should take you to the Add To-Do screen. This is how we can verify that the user is indeed on the Add screen:

let app = XCUIApplication()
XCTAssert(app.navigationBars["New Todo"].exists
 && app.staticTexts["Todo Title:"].exists
 && app.buttons[DoneButtonIdentifier].exists)

It does the job, but it’s not very clear what ‘the job’ is. Rather than seeing that everywhere we want to verify that we’re on the Add screen, we’ll just put it into a AddScreenVerifying protocol instead.

When we want to verify that we’re on the Add screen, we can just do something like XCTAssert(addScreenIsShowing()). Any file that wants to test aspects of the Add screen will have to conform to the AddScreenVerifying protocol, making it clear what the test is actually testing.

Let’s get started!

We’ll dive straight in and test the deleting of a to-do. Here’s the completed test running:

In the test, we delete a to-do titled ‘Go to Gym’. To delete the to-do, and verify that it was deleted, you need to perform these steps:

Tap on the to-do titled ‘Go to Gym’ to show the View To-do screen
Tap on the delete button
Ensure that the View To-do screen is no longer showing
Ensure that no to-do exists with the title ‘Go to Gym’

Great, with that item deleted, I’ll finally have time for some Netflix! Here’s what the test class looks like:

class ViewTodoTests: UITestCase, ViewScreenStarting, TodoListInteracting, ViewTodoScreenVerifying {
  
  let titleOfTodoForTest = "Go to Gym"
  
  func testCanDeleteTodo() {
    
    // 1
    let delete = XCUIApplication().buttons[Accessibility.View.DeleteButton]
    
    // 2
    delete.tap()
    
    // 3
    XCTAssertFalse(viewTodoScreenIsShowing(forTodoTitled: titleOfTodoForTest))
    
    // 4
    XCTAssertFalse(todo(titled: titleOfTodoForTest).waitForExistence(timeout: 1))
  }
  
}

Body of the test

Most of the magic is being done by protocols, so the actual test is very light: only four lines.

Let’s walk through it:

1. Finding the delete button

First, we need a handle on the delete button of the View To-do screen. To access a UI element from the tests, you generally use its accessibilityIdentifier property.

Using the accessibilityIdentifier is something that recording your tests won’t do. If you have a ‘Submit’ button for a form, then recorded tests will look for a button titled ‘Submit’. If the button title changes, the tests will fail. Using the accessibilityIdentifier is a way to get a handle on the button even if something like its title changes.

To find the delete button, we just look for a button with the Accessibility.View.DeleteButton identifier. I’ve created an Accessibility enum to hold the identifiers for our elements. It looks like this:

enum Accessibility {
  enum View {
    static let DeleteButton = "Delete Todo"
  }
}

This enum is a member of the UI Testing target as well as the app target, and the DeleteButton identifier is set on the the actual delete button in the app, in the ViewController for the View To-do screen:

deleteButton.accessibilityIdentifier = Accessibility.View.DeleteButton

2. Tapping on the button

Now that we have a handle on the delete button, tap it.

delete.tap()

This is the same as physically tapping the delete button on the View To-do screen.

3. Verify that the View screen is dismissed

Now that the delete button has been tapped, the View To-do screen should pop and navigate back to the main screen. What do you think this line does?

XCTAssertFalse(viewTodoScreenIsShowing(forTodoTitled: titleOfTodoForTest))

We’re asserting that the View To-do screen is not showing for the to-do that we’re testing. It reads quite well, doesn’t it?

viewTodoScreenIsShowing is defined in the ViewTodoScreenVerifying protocol to which this class conforms.

protocol ViewTodoScreenVerifying {
    func viewTodoScreenIsShowing(forTodoTitled: String) -> Bool
}

extension ViewTodoScreenVerifying {
    func viewTodoScreenIsShowing(forTodoTitled title: String) -> Bool {
        let app = XCUIApplication()
        let dateHeader = app.staticTexts["Is Scheduled For:"]
        let titleLabel = app.staticTexts[title]
        return dateHeader.exists && titleLabel.exists
    }
}

To see if we’re on the View To-do screen, we look for a couple of known elements on that screen. There should be a label titled ‘Is Scheduled For:’, and a label with the title of the to-do. If the composition of the View To-do screen changes, we only need to update the body of this function.

Any test case that is verifying an aspect of the View To-do screen will conform to the ViewTodoScreenVerifying protocol. ViewTodoTests conforms to ViewTodoScreenVerifying, so we know that it’s a test case that is verifying aspects of the View To-do screen.

4. Verify that the to-do is deleted

In the previous step, we verified that we’re no longer on the View To-do screen. Next, we need to make sure that the deleted to-do doesn’t exist any more.

XCTAssertFalse(todo(titled: titleOfTodoForTest).waitForExistence(timeout: 1))

We’re looking for a to-do with the same title as the one we’re testing with todo(titled: titleOfTodoForTest).

This test needs to interact with an element on the list of to-dos from the main screen, so we conform to TodoListInteracting to make use of this function.

todo(titled:) is a convenience function to make the task of finding a to-do a little bit easier and more readable:

protocol TodoListInteracting {
    func todo(titled: String) -> XCUIElement
}

extension TodoListInteracting {
    func todo(titled title: String) -> XCUIElement {
        return XCUIApplication().cells
            .containing(.staticText, identifier: title)
            .firstMatch
    }
}

waitForExistence gives the app some time to wait and see if the element comes into existence. We’re navigating back to the main screen from the View To-do screen, so we want to wait a bit to make sure that the navigation has completed to verify that the to-do doesn’t exist anymore.

All together now: todo(titled: titleOfTodoForTest).waitForExistence(timeout: 1) will wait 1 second, and return false if the to-do does not exist.

Wait a second…

I’ve established that the test starts on the View To-Do screen. How did we get there in the first place?

Let’s take another look at the protocol conformance of ViewTodoTests.

class ViewTodoTests: UITestCase, ViewScreenStarting, ViewTodoScreenVerifying

The class conforms to ViewScreenStarting, indicating that all tests start on the View To-Do screen. Let’s take a closer look at ViewScreenStarting.

protocol ViewScreenStarting: TodoListInteracting {
  var titleOfTodoForTest: String { get }
  func startViewScreen()
}

extension ViewScreenStarting {
  func startViewScreen() {
    XCUIApplication().launch()
    todo(titled: titleOfTodoForTest).tap()
  }
  
  func configureStartup() {
    startViewScreen()
  }
}

The magic happens inside startViewScreen.

First, we launch the app with XCUIApplication().launch(). In a UI test, the test starts with the app closed.

ViewScreenStarting also conforms to TodoListInteracting, so it can use the todo(titled:) function that we used in the body of our test. We need a to-do to open, so ViewScreenStarting has a titleOfTodoForTest property that the test case provides. Inside ViewTodoTests, we set the title of the to-do that we’re testing:

let titleOfTodoForTest = "Go to Gym"

Now startViewScreen will know which to-do item to tap.

Running code with StartupConfigurable

startViewScreen needs to run when the test starts. To do so, we use StartupConfigurable. ViewScreenStarting conforms to StartupConfigurable. It’s a simple protocol:

protocol StartupConfigurable {
    func configureStartup()
}

ViewScreenStarting calls startViewScreen from this function.

func configureStartup() {
  startViewScreen()
}

In turn, we have a base test class that will call configureStartup:

class UITestCase: XCTestCase {
  override func setUp() {
    super.setUp()
    (self as? StartupConfigurable)?.configureStartup()
  }
}

Remember, ViewTodoTests conforms to ViewScreenStarting, which conforms to StartupConfigurable. This means that ViewTodoTests conforms to StartupConfigurable as well.

When one of the tests from ViewTodoTests start, the setUp method in UITestCase will run the necessary startup work.

Tying it all together

To summarise the ViewTodoTests class:

It is a subclass of UITestCase, which allows it to run any setup code specified by conformance to the StartupConfigurable protocol. Tests will start on the View To-do screen, because it conforms to ViewScreenStarting. The boilerplate of the test is cleaned up by ViewTodoScreenVerifying and TodoListInteracting.

It can be a lot to take in, but through this approach, we gain a very simple and easy to read test:

func testCanDeleteTodo() {
  let delete = XCUIApplication().buttons[Accessibility.View.DeleteButton]
  delete.tap()
  
  XCTAssertFalse(viewTodoScreenIsShowing(forTodoTitled: titleOfTodoForTest))
  XCTAssertFalse(todo(titled: titleOfTodoForTest).waitForExistence(timeout: 1))
}

What else can we do?

For tests on the Edit screen, you need to navigate to the View screen and then tap the edit button. You could create an EditScreenStarting protocol that inherits its functionality from ViewScreenStarting:

protocol EditScreenStarting: ViewScreenStarting {
  func startEditScreen()
}

extension EditScreenStarting {
  
  func startEditScreen() {
    // Navigate to the view screen
    startViewScreen()
    
    // Tap on the edit button
    XCUIApplication().buttons[Accessibility.View.EditButton].tap()
  }
  
  func configureStartup() {
    startEditScreen()
  }
}

-Starting protocols can cascade - in this example, EditScreenStarting builds off of ViewScreenStarting. You can very easily write tests for a deep and complex ViewController hierarchy in this manner.

This does a lot to simplify the setup of tests. Combined with the -Verifying and -Interacting protocols, building UI tests is like working with building blocks - just combine the protocols you want, and the tests are easy!

What do you think of this approach? It’s definitely a work in progress, but I’ve found it to be useful in my tests. I don’t put everything into a protocol, but rather just the repetitive boilerplate, or repeated code that deserves a higher level of abstraction.

Do you have something to share? Please leave it in the comments below!

Creating a macOS Action (Gear) Button Programmatically in Swift

2018-07-17T00:00:00+00:00

For a list of actions on macOS, the standard control is an action button as defined in the macOS Human Interface Guidelines.

Here’s the definition from that page:

An action button (often referred to as an action menu) is a specific type of pull-down button that operates like a contextual menu, without the disadvantage of being hidden, providing access to app-wide or table-specific commands. An action button includes a gear icon when closed and a downward arrow indicator that alludes to its menu. Action buttons are often used in toolbars, but can also be used in the content area of a view beneath a table view.

Apple isn’t very clear about how to create one of these in code. They tell you to create a button using the system-provided gear icon by making use of the NSImageNameActionTemplate image name, but try as I might, I couldn’t replicate the action button used in Finder from that image name alone.

It turns out that there are a few more steps involved.

Create an NSPopupButton

let actionButton = NSPopUpButton(frame: .zero, pullsDown: true)

It’s clear that the button is an NSPopupButton due to the dropdown that it presents.

Position the button

view.addSubview(actionButton)
actionButton.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
  actionButton.centerXAnchor.constraint(equalTo: view.centerXAnchor),
  actionButton.centerYAnchor.constraint(equalTo: view.centerYAnchor)
  ])

Position the button where you need it. For the purposes of this demo, I’m leaving it right in the middle of the parent view. For the reasoning behind actionButton.translatesAutoresizingMaskIntoConstraints = false, take a look at my post on autoresizing masks.

We’ve created the button and positioned it in the view. This is the result:

It’s coming together!

Add some items

["Option 1", "Option 2", "Option 3"].forEach(actionButton.addItem)

An action button isn’t too useful without some actions. With an array of item titles, we use the forEach operator to add the items to the action button. You’ll see these options when clicking on the dropdown arrow.

Add the gear icon

let actionItem = NSMenuItem()
actionItem.image = NSImage(named: .actionTemplate)
actionButton.menu?.insertItem(actionItem, at: 0)

From the Human Interface Guidelines section on Action Buttons, we learnt that the .actionTemplate image name will give us the appropriate gear icon.

Don’t forget to insert the gear icon as the first item in the menu, or it won’t show up as the button’s icon.

Looking good, but we need to remove the text and the blue styling around the dropdown arrow.

Style the cell

let cell = actionButton.cell as? NSButtonCell
cell?.imagePosition = .imageOnly
cell?.bezelStyle = .texturedRounded

On macOS, most of the UI configuration is done by modifying the NSCells belonging to your views.

actionButton.cell is of type NSCell, but the properties that we need exist on NSButtonCell. We know that the cell is an NSButtonCell because the actionButton is a type of NSButton, so we cast the cell as an NSButtonCell.

Next, we set the imagePosition to get rid of the text that was displaying on the button.

To style the shape of a bordered button, we make use of the bezelStyle property. Kuba Suder has a guide to NSButton styles that is invaluable when creating buttons in code.

To get rid of the blue dropdown arrow, make use of the .texturedRounded style. That gives us our final result:

A button that fully matches the system’s action button. Here’s all of the code together:

I hope that this post has been useful to you, and that you’ve enjoyed this small foray into macOS development. Are you an iOS developer that’s been playing around with macOS? I’d love to hear about your journey in the comments below.

Autoresizing Masks and You

2018-01-23T00:00:00+00:00

You’re an Autolayout Wizard. You know Interface Builder like the back of your hand. Then, one day, you create a simple UIView, add it as a subview with some elegantly crafted constraints, and.. it blows up in your face. What gives?

Take a look at this code example that tries to create a UILabel and center it in the view.

let centerLabel = UILabel()
centerLabel.text = "Perfectly centered!"
view.addSubview(centerLabel)

NSLayoutConstraint.activate([
  centerLabel.centerXAnchor.constraint(
    equalTo: view.centerXAnchor, constant: 0),
  centerLabel.centerYAnchor.constraint(
    equalTo: view.centerYAnchor, constant: 0)
  ])

Try this, and you’ll be thoroughly disappointed. The perfectly centered label is nowhere to be found.

Luckily, the console output provides a vital clue.

[LayoutConstraints] Unable to simultaneously satisfy constraints.
	Probably at least one of the constraints in the following list is one you don't want. 
	Try this: 
		(1) look at each constraint and try to figure out which you don't expect; 
		(2) find the code that added the unwanted constraint or constraints and fix it. 
	(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) 
(
    "<NSAutoresizingMaskLayoutConstraint:0x60400009cb60 h=--& v=--& UILabel:0x7f927f2021b0'Perfectly centered!'.midY == 0   (active)>",
    "<NSLayoutConstraint:0x608000099140 UILabel:0x7f927f2021b0'Perfectly centered!'.centerY == UIView:0x7f927f1017b0.centerY   (active)>",
    "<NSLayoutConstraint:0x60400009cd90 'UIView-Encapsulated-Layout-Height' UIView:0x7f927f1017b0.height == 568   (active)>",
    "<NSAutoresizingMaskLayoutConstraint:0x60400009ce30 h=-&- v=-&- 'UIView-Encapsulated-Layout-Top' UIView:0x7f927f1017b0.minY == 0   (active, names: '|':UIWindow:0x7f927bd073a0 )>"
)

Will attempt to recover by breaking constraint 
<NSLayoutConstraint:0x608000099140 UILabel:0x7f927f2021b0'Perfectly centered!'.centerY == UIView:0x7f927f1017b0.centerY   (active)>

Looks like it’s a problem with Autolayout constraints.

` [LayoutConstraints] Unable to simultaneously satisfy constraints. `

It goes on to say:

` (Note: If you’re seeing NSAutoresizingMaskLayoutConstraints that you don’t understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) `

Looking at the conflicting constraints in the console output, we’re getting the NSAutoresizingMaskLayoutConstraints that were just mentioned.

` <NSAutoresizingMaskLayoutConstraint:0x6080000993c0 h=–& v=–& UILabel:0x7ff037604a20’Perfectly centered!’.midY == 0 (active)> `

So, it’s finally time to ask:

What the heck is an Autoresizing Mask?

Before Auto Layout, the current layout system on iOS, views were resized using the springs and struts layout system. A view’s width and height are its springs which can stretch. The struts are the view’s distance to its container. You can imagine that the view is ‘sitting’ on the struts, held in place, to determine the view’s position. The view’s springs can stretch as necessary to determine the size and shape of the view.

The autoresizing mask determines which springs and struts can change to position the view in different layouts.

The autoresizing mask can be any combination of these values:

UIViewAutoresizingFlexibleBottomMargin: Allows the bottom strut (the distance between the bottom of the view and its container) to change
UIViewAutoresizingFlexibleTopMargin: Allows the top strut (the distance between the top of the view and its container) to change
UIViewAutoresizingFlexibleLeftMargin: Allows the left strut (the distance between the left of the view and its container) to change
UIViewAutoresizingFlexibleRightMargin: Allows the right strut (the distance between the right of the view and its container) to change
UIViewAutoresizingFlexibleHeight: Allows the height spring to change
UIViewAutoresizingFlexibleWidth: Allows the width spring to change

This is a lot easier to visualize by looking at the example at Interface Builder gives you. Drag any view into a nib or storyboard. Before adding any constraints, choose the Size Inspector tab in the right pane (Alt-Cmd-5) and play with the values in the Autoresizing section.

Why does it cause conflicting constraints?

At the introduction of Autolayout, a lot of views were still laid out using springs and struts, both internal to UIKit as well as in third-party apps. For this reason, UIKit creates constraints automatically to adapt the springs and struts layout system to Autolayout.

If the translatesAutoresizingMaskIntoConstraints property of your UIView is set to true, UIKit will create Autolayout constraints that best fit your view’s autoresizing mask.

translatesAutoresizingMaskIntoConstraints is automatically set to false when you create a view inside Interface Builder and start to add your own constraints. You don’t have this luxury if you’re laying out your view in code, and you’ll have to set the property manually.

So, if you add constraints to a view created in code, you’ll most likely see conflicting constraints until you set translatesAutoresizingMaskIntoConstraints to false.

Making that change in the previous example will cause the label to display correctly.

let centerLabel = UILabel()

// Don't forget this!
centerLabel.translatesAutoresizingMaskIntoConstraints = false

centerLabel.text = "Perfectly centered!"
view.addSubview(centerLabel)

NSLayoutConstraint.activate([
  centerLabel.centerXAnchor.constraint(
    equalTo: view.centerXAnchor, constant: 0),
  centerLabel.centerYAnchor.constraint(
    equalTo: view.centerYAnchor, constant: 0)
  ])

Looking good!

You probably won’t need the autoresizing mask.

You’ll almost always be using Autolayout when laying out your views. Interface Builder sets translatesAutoresizingMaskIntoConstraints to false for you, and you’ll need to do it yourself when creating views in code.

I hope this post has been useful to you! You might already know to flip the translatesAutoresizingMaskIntoConstraints switch when you’re seeing strange behavior, but it’s helpful to get some background to help you remember.

Thanks for taking the time to read this. If you enjoyed it, please share it with your friends. I’d also love to hear your suggestions in the comments below.

Functions Deserve Injection, Too

2017-11-28T00:00:00+00:00

Lately, I’ve been taking advantage of Swift’s functional abilities where it makes sense to help me write concise and clear code that’s easy to test. I’d like to share one technique that has helped me to eliminate repetition and breakages of encapsulation in tests: function injection.

In traditional dependency injection, an object that is dependended on is passed to the method that depends on it. Function injection is my name for following the same approach when your function consumes another function.

As a code base evolves over time, a lot of small, focused utilities are added. Here’s one small utility function that I use quite often:

extension String {
    func isNonEmpty() -> Bool {
        return !trimmingCharacters(in: .whitespacesAndNewlines).isEmpty
    }
}

This eliminates the verbosity of checking if a string is empty or contains only whitespace. It is, understandably, quite easy to test as well.

    func testNoCharactersReturnsTrue() {
        XCTAssertFalse("".isNonEmpty())
    }
    
    func testOnlyBlankSpacesReturnsTrue() {
        XCTAssertFalse("         ".isNonEmpty())
    }
    
    func testNewlineReturnsTrue() {
        XCTAssertFalse("  \n   ".isNonEmpty())
    }
    
    func testNonEmptyStringReturnsFalse() {
        XCTAssertTrue("Hello there".isNonEmpty())
    }

As an example, imagine that we’re using this in an app for a clothings store. When you walk into the store, you should get a push notification from the app with a greetings message containing the user’s name. If there’s something wrong with the user’s name - if it’s empty or whitespace - we’ll throw an error.

struct Greeter {
    func greet(name: String) throws -> String {
        guard name.isNonEmpty() else { throw GreetingError.invalidName }
        return "Welcome, \(name)! Have you seen the specials on offer?"
    }
}

Let’s write some tests for this function.

We want to test two things:

The returned message is correct when the name is valid
An error is thrown when the business logic determines that a name is invalid

    func testGreetingWithValidNameReturnsGreetingString() {
        let expected = "Welcome, Caroline! Have you seen the specials on offer?"
        let actual = try? Greeter().greet(name: "Caroline")
        XCTAssertEqual(expected, actual)
    }
    
    func testGreetingWithEmptyNameThrowsInvalidNameError() {
        verifyGreetingErrorIsThrown(whenGiven: "")
    }
    
    func testGreetingWithBlankSpaceNameThrowsInvalidNameError() {
        verifyGreetingErrorIsThrown(whenGiven: "   ")
    }
    
    func testGreetingWithNewlineCharacterNameThrowsInvalidNameError() {
        verifyGreetingErrorIsThrown(whenGiven: "  \n ")
    }
    
    func verifyGreetingErrorIsThrown(whenGiven name: String) {
        do {
            try Greeter().greet(name: name)
            XCTFail("An error should have been thrown")
        } catch GreetingError.invalidName {
            return
        } catch {
            XCTFail("Incorrect error type was thrown")
        }
    }

Now, that’s a lot of tests for such a small function…

The Problem

If you look closely, you’ll see that we’re basically repeating all of the negative tests of the isNonEmpty function. If we follow this approach, we’ll be repeating the tests at every use site of isNonEmpty. That breaks the DRY principle, and it could be much worse if you had more complex logic than simply checking if a user typed a bunch of spaces for their username.

When we’re testing the greet function, we don’t actually want to be testing what it means for a string to be empty or not. That’s already been defined somewhere else in the code base. We simply want to test what the function does when it works, and how it fails when it doesn’t.

When you’re testing a component that depends on another, we make use of Dependency Injection to pass the dependence in. That way we can control the behavior. It keeps tests short and focused.

We could refactor the isNonEmpty function to its own class, and inject it either by using a dependency container or as a parameter to the greet function, but that seems like overkill. This is where the functional nature of Swift comes in. Rather than creating a class to pass as a parameter, we can apply dependency injection by injecting the function itself.

The Solution

Rather than directly calling isNonEmpty in the greet function, we’ll pass it in as a parameter.

    func greet(name: String,
               isNonEmpty: (String) -> Bool = { $0.isNonEmpty() })
        throws -> String {
            guard isNonEmpty(name) else { throw GreetingError.invalidName }
            return "Welcome, \(name)! Have you seen the specials on offer?"
    }

The new parameter has a default value set to call the intended closure. We can use it in production code without worrying about the extra parameter:

greeter.greet(name: "Batman")

This adheres to the “Clarity at the point of use” section of the Swift API Design Guidelines.

Now, when testing, we don’t need to check every permutation of the isNonEmptyFunction. We just inject a closure that returns true for testing the happy path, and we return false when testing the failure case.

    func testGreetingReturnsGreetingStringWhenNotEmpty() {
        let expected = "Welcome, Caroline! Have you seen the specials on offer?"
        let actual = try? Greeter().greet(name: "Caroline", isNonEmpty: { _ in true })
        XCTAssertEqual(expected, actual)
    }
    
    func testGreetingThrowsInvalidNameErrorWhenEmpty() {
        do {
            try Greeter().greet(name: "asdf", isNonEmpty: { _ in false })
            XCTFail("An error should have been thrown")
        } catch GreetingError.invalidName {
            return
        } catch {
            XCTFail("Incorrect error type was thrown")
        }
    }

From four tests down to two! The tests are now focused solely on the purpose of the greet function and no longer leak the implementation of isNonEmpty.

A lot of developers tend to be quite good at following dependency injection when depending on another class, but when the dependence is a function, it can sometimes be overlooked. Function injection provides the same benefits to testing and composability of regular dependency injection.

This approach can be followed whenever one function depends on the output of another. You can use it when querying important business logic, to dictate the output of utility functions, or to set the expected behavior of standard library functions.

I like how straightforward testing can be when following this approach. The most common use case for me is small utility functions that build on other utility functions.

However, make sure to use it only when it makes sense. Sometimes the right thing to do is to create a new class behind a new protocol, and then inject that protocol instead.

I’ve put the complete example code in a Playground on my GitHub account if you’d like to see more. What do you think? Do you have any alternatives? Let me know.

Have fun, and happy Swifting!

Staying Sane with Cuckoo and Code Generation

2017-10-30T00:00:00+00:00

Please note that this post won’t go over the basics of Cuckoo, as the README provides a great introduction to the library.

Do you write unit tests? You should. Writing mocks for my tests seemed to be a lot easier in Objective-C. OCMock makes great use of Objective-C’s dynamic nature and it makes mocking a breeze. However, the OCMock website has this to say:

Disappointing. Accurate.

Alright, off to find an alternative. The best that I could find was SwiftMock, but that came with an even sharper let-down:

It seems that Swift’s lack of reflection means that we’ll be doomed to doing things manually and rewriting the same type of code, again and again.

So, I resorted to rolling my own mocks. It’s not that bad. Really. I built a little mocking framework of my own based off of a Mock protocol and use of Swift’s basic reflection, and all was happy in the world of TDD.

When you’re writing a lot of code and all of the tests that should come with it, all of the time spent writing boilerplate for your mocks gets tiring. I was hungry for something more efficient.

Then, I was introduced to Cuckoo.

Cuckoo is a mocking framework for Swift that uses code generation to create the boilerplate that you’d otherwise be writing yourself. It comes with a lot of functionality that I think would be far too tedious and repetitive to do on your own. It also ensures consistency, which is something that I’ve found to be sorely lacking in the world of hand-rolled mocks.

Code Generation versus Reflection

Most programming languages use reflection to dynamically perform things that we would otherwise have to write repetitive boilerplate for. OCMock uses reflection to create mock objects. It doesn’t actually create a new class for each type you wish to mock. Reflection allows languages like Objective-C to dynamically create mocks, check for equatability, and perform JSON serialization.

As of yet, this isn’t an easy feat in Swift. The Swift language shuns dynamic behaviour and encourages safer methods. Code generation, on the other hand, fits very well with Swift’s type safety. You have code that can be read by a human and verified by a compiler.

It felt weird to me at first. I may not have written the boilerplate, but it’s still there. Written by a tool and hidden in the background. But this seems to be the way forward in a language like Swift. Frameworks like Sourcery and SwiftGen let you adopt code generation for these tasks that might otherwise be done via reflection.

The lack of reflection and strong type safety mean that code generation is the new go-to when it comes to reducing your time spent on monotonous tasks and more time working on the important parts of your app.

Cuckoo’s use of code generation has numerous benefits over the reflection approach, such as type checking, optimization, and the ability to step through and debug the generated code.

Using Cuckoo without going nuts

Cuckoo has become easier to use with a fair bit of trial and error. Here are some insights that I’ve learned so far.

Get comfortable with ParameterMatchers

Looking at this example:

stub(mock) { stub in
  when(stub.greetWithMessage("Hello world")).thenDoNothing()
}

We’re stubbing the behaviour of calls to the greetWithMessage function when passed the string “Hello World”. It’s important to note here that the code doesn’t actually expect a String object. It expects a Matchable.

The Matchable protocol is used to verify that an argument matches a set of criteria. The reason we can pass the “Hello World” string to the example above is because Cuckoo kindly extends String to conform to Matchable out of the box:

extension String: Matchable {
    public var matcher: ParameterMatcher<String> {
        return equal(to: self)
    }
}

This means that any mocked function expecting a String Matchable can be passed an instance of String.

How can we match on our own custom objects?

Say we have a logInWithCredentials function that takes a UserCredentials object as an argument. When Cuckoo generates mocks, we’ll need to pass a Matchables object to the loginWithCredentials function. We can extend the UserCredentials object just like String was extended:

extension UserCredentials: Matchable {
    public var matcher: ParameterMatcher<UserCredentials> {
        return ParameterMatcher { $0 == self }
    }
}

And now we can stub the function like so:

let testCredentials = UserCredentials(name: "Bradley", password: "pass")
stub(mock) { stub in
    when(stub.logInWithCredentials(testCredentials)).thenDoNothing() 
}

Remember that you can also do more complex checks than just comparing equality.

let matchesUserStartingWithB = ParameterMatcher<UserCredentials> { 
    $0.name.first! == "B" 
}

stub(mock) { stub in
    when(stub.logInWithCredentials(matchesUserStartingWithB)).thenDoNothing() 
}

Run the script before compiling your tests

Cuckoo’s documentation suggests that you add a Run Script phase to your test target for the generation of the GeneratedMocks.swift file that contains your mocks.

You can save yourself some time by avoiding my stupid mistake: Make sure that the Run Script phase for Cuckoo is placed before actually compiling your tests.

Break down unclear compilation errors

Cuckoo can throw some rather cryptic compilation errors when things aren’t right. Cuckoo has also been known to break the Swift compiler at times and give it a segmentation fault, in which case you won’t get the helpful red text on the line that is causing the breakage. Make sure to look carefully at any compiler errors and read the messages to pinpoint your problem.

Standard debugging techniques apply: break the issue down into its simplest parts. Eliminate all possibilities until you know what the issue is. Simplify what you’re trying to do until you get it to work, and build it up from there.

If you mismatch types, the errors can be particularly bad:

What’s happened here is that the loginWithCredentials method is expecting a Matchable for a UserCredentials object, but instead, I’ve passed it a String.

In situations like these, or when you have complex expressions and suspect that it might be impacting the compiler, it helps to strip away the type inference until things start working again. So rather than:

stub(mock) { stub in
    when(stub.logInWithCredentials(ParameterMatcher { $0.userId == 123 })).then { response in
        print(response.statusCode)
    }
}

I’d be more explicit in specifying the types, like so:

let matchesUser123 = ParameterMatcher<LoginCredentials> { $0.userId == 123 }
stub(mock) { stub in
    when(stub.logInWithCredentials(matchesUser123).then { (response: LoginResponse) in
        print(response.statusCode)
    }
}

Call verify last, not first

Here comes the facepalm moment.

Coming from an OCMock background, you may be used to calling OCMExpect before actually calling your production code:

- (void)testLoggingInCallsLoginService {
    OCMExpect([mockLoginService loginWithCredentials:OCMOCK_ANY]);
    [classUnderTest startLoginProcess];
}

Do this with Cuckoo and your tests will always fail. Calls to verify are checked when you call it, so call it after calling your other code, not before.

func testLoggingInCallsLoginService {
    classUnderTest.startLoginProcess()
    verify(mockLoginService).loginWithCredentials(any())
}

If you can’t beat them, exclude them

Structs can’t be mocked due to the fact that they can’t be inherited from (you’d stub a protocol instead). Some classes can be tricky as well, such as complex subclasses of UIViewController. Sometimes, I have a protocol in a file that I want Cuckoo to generate mocks for, and another object in that same file that I want Cuckoo to ignore. You can do this quite easily with the --exclude option:

${PODS_ROOT}/Cuckoo/run generate --testable "$PROJECT_NAME" \
--exclude "ThatStructIWantToExclude,\
ThatOtherObjectThatBreaksMyBuild" \
--output "${OUTPUT_FILE}" \
"$INPUT_DIR/FileName1.swift" \
"$INPUT_DIR/FileName2.swift"

The --exclude option is a relatively new addition that solved quite a few problems that would otherwise cause a need to revert to hand-rolled mocks. Let that be a good lesson to read the documentation frequently.

Use it when it makes sense

Cuckoo is a time saver. Spend a bit of time up front to learn its ins and outs, and you may find it to be the most efficient tool for the job. If it isn’t, don’t use it.

There are scenarios where a quick hand-rolled mock is the best way to go, and I still do it when it’s the quicker option. Be pragmatic and do what works for you and your team.

Write valuable software. Test your code. Have fun. And happy Swifting!

Lessons learned from Systems Thinking

2017-09-20T00:00:00+00:00

I was lucky enough to attend my first meetup in Poland this month: Agile Poznan. The talk was on Systems Thinking, a topic that bored me in college but fascinated me when I entered the real world. Applying systems thinking can reveal the origins behind events and behaviors we see every day. Using this clarity can make you a better software developer, and a better asset to your organisation in general.

Here are some of my insights from the meetup.

A quick definition

A system is made up of elements that share a purpose. Elements can be people, machines, or other sub-systems within the system. The elements are connected within the boundary of a system.

You can identify a system through its elements and the connections between them, its purpose, and its boundary. Identifying the elements is easy. The purpose, boundary, and connections might be a little harder to find.

It’s not the fault of the person. It’s the system.

A surprising majority of problems can be mitigated when you stop blaming the person that made a mistake, and build your system so that the problem won’t happen again. The person is just the messenger that’s showing you that the house is burning down.

Code reviews used to occasionally frustrate me before I came to this way of thinking. I’d find myself reiterating the same comments repeatedly. I want to learn, and I want to help others to learn, but learning gets diluted when we are forced to focus on miniscule issues like styling in a code review and miss the real opportunities for growth.

I see using a tool like Danger, or adding any linting or code formatting to your development pipeline, as a great application of systems thinking. You’re building safeguards in the system that will allow you to focus on more important and nuanced issues.

The performance of an organisation depends on the quality of systems, not of individuals.

The overhead of trying to micromanage every individual in an organisation outweighs the possible benefits. You simply can’t maintain it as the organisation grows and grows. The people are indispensable, but they come and go in a way that can’t be controlled. What can be controlled is the systems that the organisation runs on.

When an organisation improves its systems, the benefit is increased productivity. But it’s not just increased productivity right now, with the current teams and employees. It’s a benefit for the people there now, and those that are still to come, whether in six months or six years. Spend the initial time up front setting up a system that fosters growth, and you’ll save time and create value in the long run.

Here are some system improvements that could be used to improve company-wide performance:

Allocate a self-education budget to each employee
Issue a training manual to each new hire
Organise office space with focus and productivity in mind (i.e. avoid open plan offices)

Problems faced by an organisation can most likely be solved by a system.

It can be surprising to realise that most problems can be tied back to a system. Sometimes the system doesn’t exist yet. That’s the problem. Here are some examples of problems that might not necessarily look like system problems at the first glance, as well as a possible solution that takes the system into account:

A high frequency of software defects

Are there adequate QA processes? Could a safer programming language or framework be justified?

Underskilled developers

Try arranging weekly lightning talks related to the development that you’re doing. Chances are, there are senior developers that would love the experience and junior developers that would love to learn.

The same bugs occurring repeatedly

You fix it one day, and then it’s back the next. A company policy of writing a quick internal knowledge base article describing the cause, symptoms, and solution of the bug might help. (Two software bugs are rarely the same, and I can see this technique working better for something like tech support. However, if sharing your knowledge is what it takes to prevent yet another off-by-one error, then so be it.)

Boundaries are flexible.

Not all problems fall within the bounds of your system. How then are we meant to apply systems thinking? It’s still possible by expanding the system. One example is an app development shop that constantly deals with clients bringing in new requirements at the last minute. How can we prevent this? The client is external to the system. Changing our internal operating procedures won’t help here.

One approach is to expand the system to include the client as an internal element, not an external problem. Include them as part of your internal processes. Let them be a part of designing the end product. Ask for their feedback often. (Sounds a lot like Agile, doesn’t it?)

Fix the problem, not the symptom.

If you have an aching back, a painkiller is a great remedy. Really does the trick, right? The pain goes away in no time. The problem is when the pain comes back the next day. And next month. And again, and again.

We know not to only focus on symptoms. Get a bed that’s better suited for your back. Go for walks and get some exercise. Change sitting positions often.

The same thing can happen with software projects. When one is falling behind, we double down, add more manpower, and put our effort into shipping on time. Sometimes, it even works. Why, though, does it keep happening with all the subsequent projects?

Our focus shouldn’t be on the currently failing project. It’s just a symptom of a wider cause - a failing system. The problem doesn’t lie in the current project that’s executing, the problem lies in the system of how you execute software projects. Step back to see the wider system and its purpose, and you can apply a solution that’ll work for the current problem, as well as the next one.

A final thought

A surface level understanding and adoption of systems thinking provides a shift in perception that has proven beneficial to me. While you could do a series of lectures on the nuances and trade-offs against other methodologies, that’s not what I want from it. A wider understanding of my surroundings and what is under my control, and how to affect it, is enough for me.

Steven Covey paints a picture of the difference between managers and leaders in his book, The Seven Habits of Highly Effective People:

Envision a group of producers cutting their way through the jungle with machetes. The managers are behind them, sharpening their machetes, writing policy and procedure manuals, holding muscle development programs, bringing in improved technologies, and setting up working schedules and compensation programs for machete wielders. The leader is the one who climbs the tallest tree, surveys the entire situation, and yells, “Wrong jungle!”

I’m certain that the leader in this story was a strong systems thinker.

iOS: Animating your own toast view

2017-08-31T00:00:00+00:00

A toast view is a small, short-lived popup provides a small bite of information (see what I did there?) to the user. It’s an Android paradigm, but if you’re working on an iOS app that has an Android component, the chances are high that you have been or will be asked to implement one at some point. So you might as well learn how to make one simply without having to pull in a 3rd-party dependency, right? Well, let’s get started then.

I’ll focus on helping you get the basics of the animation down. The actual look of the view can be left to more talented designers than myself.

We’re going to animate the toast coming down from the navigation bar, but the lessons learnt needn’t be tied to the exact implementation. Create your animations as you wish. This is the final result that we’re hoping to achieve:

Animating the transform

It’s generally a bad idea to modify a view’s frame just for the purpose of animation. We’ll animate the transform instead. The responsibility of a view’s frame is setting the view’s place in the view hierarchy. The responsibility of the transform is to add any modifications to how the view should look to the user. You can modify the view’s transform to rotate it, scale it, or reposition it. We’re going to use it to reposition the view on the screen and animate that change.

@IBAction private func startToastAnimation(_ sender: Any) {
    
    let toastView = createToastView()
    view.addSubview(toastView)
    animate(toastView: toastView)
}

private func createToastView() -> UIView {
    // 1.
    let toastViewHeight = CGFloat(80)
    let toastView = UIView(frame: CGRect(x: view.frame.origin.x,
                                         y: -toastViewHeight,
                                         width: view.frame.width,
                                         height: toastViewHeight))
    toastView.backgroundColor = .green
    return toastView
}

private func animate(toastView: UIView) {
    
    UIView.animate(withDuration: 1.0, animations: {
        // 2.
        toastView.transform = toastView.transform
            .translatedBy(x: 0, y: toastView.frame.height)
    }, completion: { _ in
        // 3.
        UIView.animate(withDuration: 1.0, delay: 1.0, animations: {
            toastView.transform = CGAffineTransform.identity
        }, completion: { _ in
            // 4.
            toastView.removeFromSuperview()
        })
    })
}

1.

Firstly, create the toast view. We position it above the current view by setting the y position of its frame to be the negative of the view’s height. This will put it behind the navigation bar where the user can’t see it. It’s sneakily hiding behind the scenes until we animate it in.

2.

Translate the view’s transform by its height. A translation is a change in position, similar to how a rotation is a change in angle and a scale is a change in size. You can do translation, rotation, and scale animations using the following three methods on the transform property:

translatedBy(x:y:)
rotated(by:)
scaledBy(x:y:)

In the first step, we positioned the toast to be above the view by exactly its height. By adding a transform to move it downwards by its full height, we’ll bring the toast into position and make it appear as if it’s dropping out from behind the navigation bar.

3.

Once the animation to the view’s transform is completed, reverse the animation. It’s incredibly easy to reverse any animation on a view’s transform - just set the transform back to CGAffineTransform.identity. This is the default, unmodified transform that all views are created with. After playing around with scales, rotations, and translations, you can get a view back into its comfort zone by resetting the transform back to CGAffineTransform.identity.

4.

Once the reversal of the animation is completed, remove the view from the hierarchy. Depending on exactly what you’re animating, this step may not be necessary. For a toast view however, the view is meant to be transient, so I figured it would be best to respect that mental model of a transient toast and remove it from the view.

Where to go from here?

Play around with the timing of your animations using UIViewAnimationOptions. You can make an animation ease in or out, or set it to repeat and run in reverse.

And, when you feel ready to continue your journey to animation wizardry, start exploring UIViewPropertyAnimator. You can easily and concisely customise your animation’s timing, dynamically change its direction, and even make it user-interactable.

Have fun, and happy Swifting!

iOS: Working with Images from a Server

2017-07-04T00:00:00+00:00

If you’re a mobile app developer, at some point in time you’re going to need to interact with a backend. One of the tasks you might need to do is to retrieve and display images from a server, or submit an image to that server. What format should the image be in when you’re submitting it? How do you convert bytes received from a service call into an image?

Let’s build the entire stack from the server to an iOS App to find out how.

Setting up a backend

We’ll start off by building a Kitura server that provides a RESTful API to do two things:

Receive images from a client
Provide the most recent image that was received to a client

I’ve put the finished server up on my Github.

Create the server project

Make a directory, and init a new executable Swift package.

mkdir mkdir SwiftImageServer && cd SwiftImageServer
swift package init --type executable

Edit your Package.swift file to specify that you require the Kitura package.

import PackageDescription

let package = Package(
    name: "SwiftImageServer",
    dependencies: [
      .Package(url: "https://github.com/IBM-Swift/Kitura.git", majorVersion: 1)
    ])

You can run a swift package fetch and you should see SwiftPM cloning Kitura and everything that it requires.

Spin up a xcodeproj with swift package generate-xcodeproj and let’s get coding!

Create a Kitura server

The backend is going to be super simple, so we’ll just be working in main.swift.

Let’s start off by adding all the boilerplate that we need:

import Kitura
import Foundation

// Create a Router that we can use to create REST endpoints
let router = Router()

// Specify that we want an HTTP server that we can reach with http://localhost:8090
Kitura.addHTTPServer(onPort: 8090, with: router)


// Start the server
Kitura.run()

I love how easy it is to create something these days. Three lines of code and you have a server running. It’s a shame that it can’t do much. Let’s fix that.

Returning an image from a GET endpoint

var latestImage: Data? = nil

// http://localhost:8090/latestImage
router.get("/latestImage") {
    request, response, next in
    
    defer { next() }
    
    guard let image = latestImage else {
        response.status(.preconditionFailed).send("No image is available")
        return
    }
    
    response.send(data: image)
}

You thought we were sending images, you say? That looks like a Data object, not a UIImage? That’s where the fun comes in. You never send an image as an image. All images are simply data packaged in an easy to use format. When we’re sending images to and from our server, we need to package it as a Data object and send that instead. We’ll represent it as a UIImage in our iOS app.

Notice the guard let image = latestImage. That’ll fail until we set the latestImage variable. Let’s build the endpoint that receives an image, so we can set the latestImage variable.

Submitting images to a POST endpoint

Next, we’ll build the endpoint that will be used to submit images.

// Create a POST endpoint: http://localhost:8090/image
router.post("/image") {
    request, response, next in
    
    defer { next() }
    
    var data = Data()
    
    do {
        // Read the body of the request into the data object
        try _ = request.read(into: &data)
        latestImage = data
	response.status(.OK).send("Image received")
    } catch(let error) {
        response.status(.internalServerError).send("Something went wrong when reading the image data")
    }
}

We’ve created an endpoint that expects a POST request with a raw body of the image data. Remember, the server only knows Data, not UIImage, so the iOS app is going to have to convert the image to a Data object.

That’s our entire server done!

Up and running

Here’s a link to the completed server: https://github.com/TheCodedSelf/SwiftImageServer

Run the executable target. That’s the one with the Matrix-style computer screen, not the yellow lunchbox.

Keep that running, and we’ll build the iOS app.

The client app

The complete example code for the iOS app is available on my Github.

Create the project

Create a new Single View iOS Application. We’re going to need to modify the Info.plist. We need permission to access the Photo Library to pick an image. We also need to modify the App Transport Security settings to make HTTP network requests, as opposed to HTTPS (our local Kitura server is HTTP).

Add the following to the project’s Info.plist:

Submitting images to the server

We’re going to add a button that’ll allow us to select an image from the photo gallery and submit it to the server we built earlier.

We’ll start off by adding a button to the view controller in Main.storyboard:

Now, hook it up to ViewController.swift and add the code to post it to our backend.

Let’s connect an IBAction to the ‘Pick Image’ button where we pick an image using a UIImagePickerController.

@IBAction func pickImage(_ sender: Any) {
        
        guard UIImagePickerController.isSourceTypeAvailable(.photoLibrary) else { return }
        let imagePickerController = UIImagePickerController()
        imagePickerController.sourceType = .photoLibrary
        imagePickerController.delegate = self
        present(imagePickerController, animated: true, completion: nil)
    }

We’re setting the ViewController as the UIImagePickerController’s delegate. Add an extension that conforms to the delegate protocol that also handles any picked images. Setting the delegate also requires conformance to UINavigationControllerDelegate, so add that in as well.

extension ViewController: UIImagePickerControllerDelegate, UINavigationControllerDelegate {
    
    public func imagePickerController(_ picker: UIImagePickerController, didFinishPickingMediaWithInfo info: [String: Any]) {
        
        if let image = info[UIImagePickerControllerOriginalImage] as? UIImage {
            submit(image: image)
        } else if let image = info[UIImagePickerControllerEditedImage] as? UIImage {
            submit(image: image)
        }
        
        picker.dismiss(animated: true)
    }
}

We can select an image, and we’re ready to handle it. Notice the submit(image:) function in the above example. We’ll create that function now, and submit the image to our server.

func submit(image: UIImage) {

        let session = URLSession(configuration: URLSessionConfiguration.default)
        
        guard let url = URL(string: "http://localhost:8090/image") else { return }
        var request = URLRequest(url: url)
        
        request.httpMethod = "POST"
        request.httpBody = UIImagePNGRepresentation(image)
        
        let dataTask = session.dataTask(with: request) { (data, response, error) in
            
            if let error = error {
                print("Something went wrong: \(error)")
            }
            
            if let response = response {
                print("Response: \n \(response)")
            }
        }
        
        dataTask.resume()
    }

Receiving an image from the server

Now that we have the ability to submit images as Data objects, we need to build in the functionality to receive an image as Data and convert it to a plain old UIImage.

Start by adding an image view and another button to the view controller in Main.storyboard:

When the user taps on the new button we’ll call the latestImage endpoint to retrieve the last image that was sent to our server as a Data object. We’ll then convert it to a UIImage and display it in the image view.

@IBOutlet weak var imageView: UIImageView!
    
    @IBAction func showLatestImage(_ sender: Any) {
        
        let session = URLSession(configuration: URLSessionConfiguration.default)
        
        guard let url = URL(string: "http://localhost:8090/latestImage") else { return }
        
        var request = URLRequest(url: url)
        request.httpMethod = "GET"
        
        session.dataTask(with: request) { (data, response, error) in
            
            if let error = error {
                print("Something went wrong: \(error)")
            }
            
            if let imageData = data {
                DispatchQueue.main.async {
                    self.imageView.image = UIImage(data: imageData)
                }
            }
        }.resume()
    }

Looking good. You completed ViewController should look like this one: https://github.com/TheCodedSelf/LatestImageRetriever/blob/master/LatestImageRetriever/ViewController.swift

A Finished Product

Here’s our app that has submitted an image to the server and pulled an image from the server to display.

When you tap on Pick Image, you’re presented with a UIIImagePickerController that allows you to select an image from the Photos Library, and submits it to our backend after converting it to a Data object. The Show Latest Image button does a GET request to our server to retrieve the last image that was sent, converts it to a UIImage, and then displays it in our UIImageView.

You should now have a basic understanding of how to send objecs besides text to a server - and how to retrieve them. Congratulations!

Have fun, and happy Swifting!

Vim and Swift: Development in a post-apocalyptic world

2017-06-22T00:00:00+00:00

Disclaimer: I don’t advocate using Vim seriously as your primary development environment. As powerful as it is, Vim remains a text editor, not an IDE.

I ran into some Xcode problems the other day where I lost syntax highlighting and code completion in Swift files. What should we do when Xcode just doesn’t work?

I joked that at this point, it might be easier to just use Vim for my Swift development.

Well…

It’s not hard to use an arbitrary text editor to write some code and then run it through a compiler. For this setup, we want something a little bit more pleasant to use. The passionate programmers that we are, we want to be able to work on non-trivial Swift projects, with or without Xcode, from the comfort of our own home or in a post-apocalyptic nuclear bunker (hey, let’s not rule anything out).

We want:

Those sweet Vim keybindings
An easy way to compile and run code
Resilience against Xcode temper tantrums
Syntax highlighting that works. All. The. Time.

We’ll be using some Vim plugins. You’ll need some means of plugin management. I’ll be using Pathogen.

Syntastic

Syntastic provides syntax highlighting in Vim for many languages. It does this by associating checkers with a particular language. When you save the file you’re working on, it runs the appropriate checkers. A checker is essentially an adapter between the world of Vim with Syntastic and your language with its compiler or linter. What we want to accomplish through Syntastic is to easily compile a project when the current file is saved and surface any errors or warnings inside Vim.

Using Pathogen, install Syntastic.

cd ~/.vim/bundle && \
git clone --depth=1 https://github.com/vim-syntastic/syntastic.git

swift.vim

swift.vim has a SwiftPM checker that will compile a project and a SwiftLint checker to remind us that we occasionally have no idea what we’re doing.

Install swift.vim:

cd ~/.vim/bundle && \
git clone --depth=1 https://github.com/keith/swift.vim

SwiftPM

Go to a Swift project containing a Package.swift (The manifest file for SwiftPM) and open a Swift file in Vim. Run :SyntasticInfo and you should see some output from Syntastic:

The important tidbit here is that the swiftpm checker is available and enabled. This means that when we save the file, it’ll run swift build to build the package.

SwiftLint

To get the SwiftLint checker working, we need to start off with: brew install swiftlint.

If you want to configure SwiftLint to your tastes, you’ll need to add a .swiftlint.yml file to your Swift project to get the syntax checker working. Or, if you’re happy with the global default, add this to your .vimrc:

let g:syntastic_swift_swiftlint_use_defaults = 1

Adding that will let you have some awesome linting without needing to add a configuration file to every project.

If you tried this in a project that has the SwiftPM checker enabled, you might run into a slight problem: :SyntasticInfo notes both the SwiftPM checker and the SwiftLint checker as available, but neither are enabled. Add the following to your .vimrc to enable both:

let g:syntastic_swift_checkers = ['swiftlint', 'swiftpm']

Individual Swift Files

SwiftPM is great, but sometimes it’s a little bit much when I want to create a short script. I created a Syntastic checker that will work a single Swift file to run the script when you save it and show any errors inside Vim.

Install syntastic swift:

cd ~/.vim/bundle && \
git clone --depth=1 https://github.com/TheCodedSelf/syntastic-swift.git

If you’re only working on a single Swift file, you can use this checker - no need to go through the hassle of setting up SwiftPM. Just remember to add the checker in your .vimrc if necessary:

let g:syntastic_swift_checkers = ['swiftlint', 'swiftpm']

Unfortunately, while the checker will surface any errors in Vim, it doesn’t show any output from running the Swift script. I added a mapping to my .vimrc to sort this out:

nnoremap <leader>sb :!swift %<CR>

By hitting my leader key followed by sb, the current script will run and you’ll be able to see any output.

Moving Forward

You can compile SwiftPM projects, run Swift scripts, and use SwiftLint to patch up your mistakes, all while remaining in the warm embrace of Vim.

The next time you’re having troubles with Xcode, or if you just want to practice your Vim-fu, why not take this a bit further?

Have fun, and remember: learning is living.

Your Other Job

2017-06-05T00:00:00+00:00

You are the CEO of a company.

There is no board of directors. The fate of the company lies solely on you.

Every day, you make decisions that determine the success of the company. Some days you might make good decisions, and some days you won’t.

You might have some trusted advisors that guide you in your role as CEO. But it’s not their job to lead the company to success, it’s yours. You can take their advice or you can ignore it, but it’s important for you to remember that it’s your choice, and your responsibility.

The company is yourself.

Each of us make decisions throughout our lives that have the power to guide the direction that we take. You decide how to spend your spare time, what career path to follow, what projects to work on. You decide when to rest and when to keep working. Remember that each action that you take is tallied into whether or not the company becomes successful.

Half-Baked Solutions to Common RxSwift Problems

2017-05-23T00:00:00+00:00

I’ve been using RxSwift in some of my latest iOS projects. While I feel that it’s provided elegant UI binding and a natural feel to asynchronous programming, I have to admit that it came with numerous growing pains. I struggled to find documented solutions to some of the challenges I was facing, as RxSwift is not as widely adopted as its more affluent Java and .Net counterparts. Here are some of those hurdles that I faced, along with my solutions.

Why can’t I access the tap method of my UIButton?

One of the greatest benefits of Rx is its UI binding capabilities. So you must imagine how peeved off I was when I couldn’t do something as simple as bind some logic to taps on a UIButton. Luckily, the solution is just as simple as the problem.

import UIKit
import RxSwift
import RxCocoa

let button = UIButton()
button.rx.tap.bind {
    print("That wasn't too hard, was it?")
}

See that sneaky import RxCocoa at the top there? RxSwift functionality relating to UIKit is found in the RxCocoa module. The rx property on UIButton that I’m using in the snippet comes from RxCocoa. You can find it on most UIKit objects. It’s what powers RxSwift’s interaction with UIButton, UITableView, UIImageView, and all of the other usual suspects. You can find an RxSwift extension on most UIKit objects - just look out for the object plus Rx.swift - e.g. UITableView+Rx.swift.

How do I combine the output from multiple observables into one?

If you have data from multiple sources, and want to treat them as one, you need to merge them.

let cars = Observable.from(["Nissan", "Ford", "BMW"])
let tanks = Observable.from(["Tiger II", "T-44", "Panther"])
let bikes = Observable.from(["Ducati", "Honda", "Kawasaki"])

let landVehicles = Observable.of(cars, tanks, bikes).merge()

landVehicles.subscribe(onNext: { print($0) })

/* Output:
Nissan
Ford
Tiger II
BMW
T-44
Ducati
Panther
Honda
Kawasaki
*/

First, we combine the three observables using of. You can use the of operator on any list of items to create an Observable from said items. Used here, it gives us an Observable of Observables.

The merge operator is used to flatten out an Observable of Observables. We use it to create the landVehicles observable, which is an Observable of Strings.

How do I make one observable depend on another?

I have one observable that initiates a service call when I subscribe to it. However, I only want to execute that service call if my view passes validation successfully. I have another observable that returns an error event if validation fails. If the validation observable submits an error event, the service call observable should not execute.

Here’s the solution that I came up with:

func submit(number: Int) {
    let validateAndPerformServiceCallIfSuccessful =
        performValidation(numberThatShouldBeEven: number)
            .flatMap { () -> Observable<Void> in // 1
                print("Validated successfully")
                return performServiceCall() // 2
    }
    
    validateAndPerformServiceCallIfSuccessful.subscribe(onNext: { _ in
        print("Service call was a success!")
    }, onError: { _ in
        print("Something went wrong.")
    })
}

private func performValidation(numberThatShouldBeEven: Int) -> Observable<Void> {
    if numberThatShouldBeEven % 2 == 0 {
        print("Validation succeeded.")
            return Observable.just(())
    } else {
        print("Validation failed.")
        let error = NSError(domain: "com.thecodedself.rxswift",
                            code: 0,
                            userInfo: nil)
        return Observable.error(error)
    }
}

private func performServiceCall() -> Observable<Void> {
    print("Performing service call")
    return Observable.just(()) 
}

If an even number is passed to the submit function, the service call is executed. If the validation fails, an error message is printed on the screen.

Here’s an explanation of what’s happening:

flatMap over the performValidation observable. When you flatmap an observable, any time the observable sends a next event, your closure will execute and you’ll return another observable. If the observable that you’re flatmapping sends a completed or error event, the observable is finished executing - that means no service call.
Any time the performValidation observable sends a next event, return the performServiceCall observable. What this means is that the validateAndPerformServiceCallIfSuccessful observable will send an error or completed event if either performValidation or performServiceCall send an error or competed event. The meat of it lies in the flatMap closure - if the performValidation observable sends a next event, the performServiceCall observable gets to do its thing.

This pattern does seem complex, but it can be insanely powerful once you learn it and use it to your advantage.

Testing with RxSwift is horrible. How can I make it less horrible?

Well, that’s a very valid point. Testing against the RxSwift framework can be difficult on its own, involving asynchronicity and a lot of complex logic in your tests. Luckily, we have RxBlocking.

RxBlocking is a library in the same GitHub repository as RxSwift. If you’re using Cocoapods, just add pod 'RxBlocking' to your test target.

No dealing with TestSchedulers and XCTestExpectations. If you can work with an array, you can work with RxBlocking.

class FibonacciFinderTests: XCTest {
    
func testThatThreeFollowingFibonacciNumbersAreReturned() {
    let expectedNumbers = [13, 21, 34]
    
    guard let actualNumbers = try? FibonacciFinder().findThreeFollowing(number: 9)
        .toBlocking()
        .toArray() else {
            XCTFail()
            return
    }
    
    XCTAssertEqual(expectedNumbers, actualNumbers)
    }
}

The above snippet tests the findThreeFollowing function on the FibonacciFinder class, which, given a number, should return the first three numbers that follow it in the fibonacci sequence.

Calling toBlocking on an observable returns a Blocking Observable, which is an observable with added functionality to block your thread of execution so that you can test it without having to worry about asynchronicity. We then call toArray, which handles subscribing to the observable and returning any next events neatly packaged in an array for us for easy of testing. Note that toArray can throw exceptions, which is why we have the try statement and a guard clause.

Still a lot more to learn

As I write more RxSwift code, and occasionally run into barriers, I learn a little bit more about the library and improve the quality and readability of my reactive solutions. It’s tough in the beginning, but as you get more comfortable, RxSwift starts to show its utility. Don’t be afraid to dive in and read the implementation code and try different things.

Enjoy your Swifting!

Lessons Learned From The Entelect Way

2017-05-08T00:00:00+00:00

Software engineering and coding are two very different concepts. As a software engineer, I write code on a daily basis, but the value that a good software engineer provides to a business is so much more. This is emphasised by The Entelect Way.

What is The Entelect Way?

I’m a software engineer at Entelect, a software engineering and solutions company based in South Africa. The Entelect Way is a set of guiding principles for software delivery that can be used to help guide your decisions, activities, and behaviour as a professional software engineer. The principles are broken down into the following areas of focus:

Agile Planning and Development
Software Engineering Quality Practices
Individual Growth
Team Engagement
Relationships
Value Adding Activities
First Class Service Delivery

The Workshop

A few weeks ago, my team attended a workshop on The Entelect Way with a few teams based at other clients. We took a deeper look at each of the principles and were encouraged to find ways to apply these principles in our day to day activities.

Our Findings

We were asked to discuss Value Adding Activities. We chatted about each team’s strengths and weaknesses around the points raised during the workshop. I realized what our team does well - and where we need some major improvement. While we didn’t stay entirely on topic of Value Adding Activities, we did manage to learn a lot from each other that we then compiled into a list. Here’s the best picks across our three teams:

Focus on your client’s ‘why’

You can take action on your client’s what, or you can take action on their why. Try to find the why, and use that as your guide.

Imagine you’re fetching data from a service and displaying that to the user. If someone asks you to attempt to make the service call three times in the case of failure before displaying an error message, they’re asking for the what. The why is likely to be something along the lines of “I don’t want the user to visually experience errors when the server goes down”. Now that you know what they hope to achieve, you know that your task is to build more resilience into the app and reduce downtime. You as a knowledge worker likely know the best approach to achieve this, and you can use your experience to solve the client’s actual need.

Communicate constantly to understand your client’s intention

This is pretty much the crux of agile software development. How do you know that you’re building a product that will give the client the most possible value? You communicate. Constantly. Raise concerns. Show progress. Share ideas. If you open up that dialogue, your client will happily communicate back and share what they really had in mind. This level of communication will get you on the same wavelength.

Commit to your own work

There’s nothing worse than giving an estimate and seeing it being ignored. When you’re asked to commit to goals that you don’t see as feasible, it leads to demotivation and shoddy results.

Emphasize the importance of taking responsibility of your own estimates and commitments. Rather than being forced to take on work that you didn’t sign up for, you now have the motivation and autonomy of playing a pivotal role in reaching an objective that you helped to set.

Use deadlines to your advantage

A deadline doesn’t need to be a negative thing. It defines the expectation that is laid on you and, when realistic, can be an effective measuring stick for you to gauge the value that you are providing to your company.

By pacing yourself against a deadline, you’ll have an end goal that you work towards. The satisfaction from meeting a realistic deadline that you’ve committed to can be a great motivator towards reaching the next deadline.

Make use of the rhythm of sprints

Sprints provide a good set routine for you to find time for other value-adding activities. By ringfencing a chunk of work to the boundaries of a sprint, you provide time for activities such as reducing tech debt, setting up build automation, and finding ways to improve the way your team works on a daily basis. Use the quiet time provided by the cadence of a sprint to focus on ways to improve.

Do more than just code

A set of principles like those found in The Entelect Way helps one to realize that there is more to software development than just writing code. There are a lot of areas of concern that we need to focus on before we can define ourselves as true professionals. Following some guidelines and making deliberate effort towards putting them into practice is how we can provide true value: whether for a client, for your company, or for yourself.

Android Development Through the Eyes of an iOS Developer

2017-03-16T00:00:00+00:00

I’ve recently dipped my toes into Android development to see the differences in environment and tooling as compared to iOS development. While I haven’t done much as of yet, I hope to ship some Android apps in the future alongside some iOS ones. I figured it was time to understand the platform so that I can better relate to the woes of Android development.

Disclaimer

Note that this is entirely opinion based, and these are only initial opinions. Understanding of any language or SDK fleshes out over time, and I’m looking forward to see how my understanding and opinions change as I write more and more Android code.

The Findings

I expected to see much more boilerplate and repetitive code as opposed to iOS, where we have the ability for frameworks to be more powerful and simple at the same time by tapping into the Objective-C runtime. While this was true to some extent, I’d like to talk more about some of the other differences I noticed:

IDE

If you’re ever used a Jetbrains IDE or plugin, you’ll love Android Studio. It’s such a pleasure having the platform’s standard IDE being one by Jetbrains. I’ve been burned by Xcode too many times, namely due to bugs and lack of refactoring tools, and I for one am quite pleased with Android Studio.

Activities vs ViewControllers

Where you’d use a UIViewController in iOS, you’re using Activities in Android. While passing data through Intents is not perfect in my eyes, I prefer it to using the prepareForSegue method on iOS to see if the segue identifier matches the one you expect and then configuring the destination view controller. However, if you don’t need to pass data around, I must say that handling all your segues in a Storyboard without writing any code is very convenient.

Supporting different platforms and devices

I’m starting to see that we have it so easy on iOS when it comes to supporting other devices. There’s an almost unlimited number of hardware and screen size combinations for Android. Many iOS developers can name almost every possible device that their apps can run on out of the top of their heads, and that’s not something to take for granted. On Android I can see a need for a few if statements like the following:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB)

On iOS, the amount of versioning checks is considerably less due to the practice of only supporting version N-1 (meaning today, I would support iOS 10 and iOS 9, but drop any support for iOS 8). This is a luxury that Android does not have.

Localization

Android specifies string resources in XML. Specific locales are XML files with the ISO country code in the name. iOS has a similar structure but with a nasty .strings file instead of XML where standard practice is to specify strings like the following: “home.loggedin.title” = “Hello, World!”; or even worse: “Hello, World!” = “Hello, World!”;

In use:

myLabel.text = NSLocalizedString(“Hello, World!", comment: “")

What I like about Android is that it’s strongly typed.

textView.setText(R.string.hello_world);

The first project that I built while trying to learn Android was an activity with a text field and a button.

When you tapped on the button, you’d be presented with another activity with a label that contained the text from the previous activity’s text field.

I was quite pleased with myself until I realized that I had forgotten to put in a navigation bar to get back to the first activity. Ugh, now I have to figure out how to embed everything in a navigation bar. How do you even make a navigation bar in Android? It took me a few seconds before I remembered that Android devices always have a back button. Lo and behold, a functional navigation hierarchy without implementing a UINavigationBar! Feel my power!

Dynamic Views

Activities can contain Fragments, which is sort of like a ViewController containing multiple ViewControllers as children and receiving all lifecycle calls that the Activity receives. You can easily add Fragments to an Activity in XML or in code using the FragmentManager class. No messing with Storyboards and Nibs and making sure that you correctly tie everything up!

The Android Developer training documentation shows how you can get the behavior of a UISplitViewController that shows two views on a tablet, but uses a navigation hierarchy to navigate between the two views on smaller devices:

Except with Fragments, you’re not limited to that layout.

Storing Data

You may whine about Core Data now, but there’s nothing in Android stopping you from executing arbitrary SQL queries. You have the SQLiteOpenHelper class to guide you but other than that it’s pretty much up to you to manage your database. At least we now have Realm on both platforms to help us overcome the database nightmare.

Android Development Going Forward

Why would an iOS developer want to learn Android development?

They capture the majority of the market, especially in developing countries
Users expect apps to be available on both iOS and Android
It’s a natural way to expand your skill set: a new language and SDK, but still the same mobile paradigm

I’m excited to take on more Android development going forward.

Using Multiple Author Identities With Git

2017-02-15T00:00:00+00:00

How do you manage git credentials for different organizations? You may have some projects you work on at work that has a pre-push hook to ensure that your email is part of the correct domain. You might have your own personal projects, some of which might also use difference email addresses. Or, just maybe, you have a secret identity that you don’t want your other repositories to know about. How does one manage this schizophrenic multiple personality disorder that we call Version Control?

If I commit with the wrong email at work, I won’t be allowed to push to our internal Bitbucket server. If I commit with the wrong email on one of my personal Github repositories, I end up with this ugly situation:

The commits that don’t have my image were made with my name but with an unknown email. So GitHub doesn’t know that it was really me and does not link it to my Github identity. What I need to do is to tell git to use the email that Github expects.

How to assume multiple identities

Git commits have an author with a name and an email. Run git log in a repository you’ve committed to recently to see some of the metadata of your commits:

commit bd294498cbd5c67b51096518ce62c9204068be2c
Author: Bruce Wayne <bruce.wayne@wayneenterprises.com>
Date:   Tue Feb 14 19:58:34 2017 +0200

    Plan attendance to charity events

Git uses the user name and email set in your global .gitconfig file, located at ~/.gitconfig or C:\Users\MyUser\.gitconfig. The [user] block sets the author name and email address for all commits. You can set it by manually editing the file:

$ vim ~/.gitconfig

[user]
        name = "Bruce Wayne"
        email = "bruce.wayne@wayneenterprises.com"

Git also provides a command to update global settings.

$ git config --global user.name "Bruce Wayne"
$ git config --global user.email bruce.wayne@wayneenterprises.com

This modifies the global .gitconfig for you.

Specifying identities at the repository level

So now that you’ve created your global identity, how about adding a different one for a particular repository? Each repository has its own config file in which you can override the global configurations - it’s located in the hidden .git folder. Take a look at .git/config inside your repository.

To create your repository-specific secret identity, edit the file and add a user config to override the global one:

$ vim ~/.gitconfig

Or, you can run the git config command and specify the change as being local to the repository.

$ git config --local user.name "Batman"
$ git config --local user.email "batman@justiceleague.com"

This is the configuration that you should end up with in .git/config:

[user]
        name = "Bruce Wayne"
        email = "bruce.wayne@wayneenterprises.com"

Now, you can use Git under your secret identity!

Author: Batman <batman@justiceleague.com>
Date:   Wed Feb 15 04:53:57 2017 +0200

    Create initial blueprints for Batcave

That’s too late for me, I’ve already committed with the wrong author email!

Sometimes you make a mistake, like this one here:

Author: Bruce Wayne <bruce.wayne@wayneenterprises.com>
Date:   Thurs Feb 16 19:21:35 2017 +0200

    Fight crime in downtown Gotham

With a commit author like that, Batman’s secret identity is surely at risk of being compromised. Luckily, you still have the opportunity to modify this commit before you push it upstream.

Warning

All of the suggestions listed below modify your git history. This means that if you’ve already pushed your changes upstream, you’ll have to force push your changes. Even worse, if the changes are upstream and another developer has been working on that branch with the commits that you’re about to change, things can get really tricky. The safest decision is to refrain from modifying commits that are already publicly visible to other developers.

Amend the latest commit

If the commit that you need to change is the most recent commit, you can easily change it like this:

$ git commit --amend --author="Author Name <authoremail@example.com>"

git commit --amend allows you to change the commit message if you choose to, and the --author="Author Name <authoremail@example.com>" part sets the author name and email to whatever you’ve specified.

You can use it to modify the previous commit to the following:

Author: The Dark Knight <batman@justiceleague.com>
Date:   Thurs Feb 16 19:21:35 2017 +0200

    Fight crime in downtown Gotham

Even Batman needs a helping hand sometimes.

Interactive rebase

One of my favourite tricks, the interactive rebase, can be used to commits other than the most recent one. This tutorial should get you up to speed with how to do a rebase.

To amend commit authors, we run an interactive rebase, specify to edit the commits that we want to change, and then run the git commit --amend --author command we used previously to edit the commit’s author.

$ git rebase -i head~4

We’ve started an interactive rebase. We’ll be presented with a text editor containing the following:

pick fe79802 Buy new batmobile
pick 04a7c9c Dent new batmobile
pick 2a826b2 Attend Policeman's Ball
pick 1d12e8c Defuse bomb before detonation

# Rebase 56d3e50..1d12e8c onto 56d3e50 (4 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

We attended the Policeman’s Ball under Batman’s identity, but it should really be Bruce Wayne. On the third line, change pick to edit.

edit 2a826b2 Attend Policeman's Ball

Now we can amend the commit to set the correct author.

$ git commit --amend --author="Bruce Wayne <bruce.wayne@wayneenterprises.com>"

When you’re done, run git rebase --continue to move to the next commit that you specified to edit, or to continue to the end of the rebasing session.

Bulk change commits

Using the git filter-branch command, which is way beyond the scope of this blog post, you can do all kinds of crazy things. One of the more reasonable usages is to inspect every commit in your repository, check if it matches a particular email address, and if so, change it to a new one.

I’ve create a Gist on Github to do this: author-amend

Just save it in the root of your repository and execute it, or copy it and paste it in your terminal.

Change the values of OLD_EMAIL, CORRECT_NAME, and CORRECT_EMAIL to suit your needs.

Changing author identities is not that hard.

Once you’ve been introduced to the right commands, there’s always a way to coax git into suiting your needs. There’s no need to put up with incorrect names, and definitely no need to scrap the commit and start again.

So, when something’s gone wrong:

Remember, git commit --amend is your friend.

Thanks for taking the time to read this, and I hope you learned something that might prove helpful in the future. If you did, please take the time to share it on Facebook, Twitter, Reddit, or whatever it is that people are using these days.

The Difference Between An Adapter And A Wrapper

2017-01-30T00:00:00+00:00

The adapter pattern and wrappers each solve common but distinct problems. Their common usage and similarities in implementation, however, can lead to confusion. Both terms seem to be used interchangeably when in fact there are a few key differences. The adapter pattern and wrappers are two very useful tools and you can benefit from having them properly labeled in your toolbox.

Definition

Adapter: An adapter allows code that has been designed for compatibility with one interface to be compatible with another. An adapter accomplishes this by transforming the input meant for Interface A into compatible input for Interface B. It is a bridge between two existing interfaces.

Wrapper: A wrapper encapsulates and hides the complexity of other code. The most common use of a wrapper is in the Facade pattern. Third-party code can be hard to use due to the fact that the exposed interface is made to accommodate many use cases. When you are only concerned about a subset of the features or the exposed interface, or you find that using the library is hard or tedious, then what you need is to wrap it in a simpler, more constrained interface.

Differences

Intention: The end product may look similar but the intention is different. A wrapper as used in the Facade pattern is intended to simplify an interface to an external library. An adapter is intended to bridge the disconnect between one interface and another. You may look at a new library that you wish to use and write a wrapper to simplify and streamline its use. You may look at an interface, internal or external, that your existing code needs to conform to, and write an adapter to do that.
Composition: A wrapper contains another object and wraps around it. It has the the sole responsibility of moving data to and from the wrapped object. An adapter doesn’t necessarily contain or simplify an object, although this can be a secondary benefit of using adapters. An adapter transforms input to make it match the input required by another interface. It adapts input to that other interface.
Problem space: An adapter solves a problem of incompatibility, while a wrapper fulfills the need of a simplified and specific programming interface.

Example

Imagine inserting a 2-prong plug into a 3-prong wall socket by using an adapter. That plug adapter is akin to the adapter pattern, whereas the actual plug is a wrapper around the live wires inside.

The live wires have all of the functionality you need, but the wrapper - the plug - simplifies things. It has all of the functionality with none of the danger.

Your 2-prong plug isn’t compatible with the 3-prong wall socket, however. You need an adapter to map the 2-prong plug’s interface to what is expected by the 3-prong socket’s interface.

Let’s see some code!

Imagine a new feature of your app needs to integrate with social media to get some basic user info. A FacebookConnector class would be a wrapper around Facebook. It facilitates your connection to Facebook. Rather than talk to Facebook’s SDK which exposes many different use cases, you create a class that talks to the SDK for you, and only exposes what you need. I have a Facebook wrapper that I used for a Swift app on my Github profile.

What if you know that you need some particulars from social media - a user’s email, a full name, perhaps a profile picture or a personal description? You don’t know what particular social media that you’d like to integrate with. Quite frankly, you don’t care as long as you can get the info that you need. In this scenario, you’d make an ISocialIntegrator interface, defined as following in C#:

interface ISocialIntegrator
  {
  void Connect();
  string Email { get; }
  string FullName { get; }
  string Description { get; }
  }

Notice how the actual social network is not mentioned. The interface is agnostic of whatever social network is being used under the hood.

Now that you’ve defined the interface that the rest of your code will interact with, you can start developing against the interface without worrying about its actual implementation. After a two or three well-earned beers, once you make the choice of the particular social media that you’d like to use, you can create an adapter between your SocialIntegrator interface and the social media that you’ve chosen. You can create a FacebookAdapter, LinkedInAdapter, etc. which will conform to the SocialIntegrator interface and bridge the gap between the generic info that you need and the actual API of the social network that you’ve chosen.

Summary

Being cognizant of what problem you are trying to solve and what pattern you are using to solve that problem will help you to keep your code clean and focused on a singular purpose.

Use wrappers to simplify code, encapsulate third-party dependencies, and eliminate repetition.

Use the adapter pattern to allow yourself to swap out third-party dependencies at will by interacting with your own interface, and then making adapters that map from your own interface to the third party code.

Server Side Swift With Kitura And Bluemix

2017-01-03T00:00:00+00:00

IBM Bluemix is a cloud Platform as a Service solution that enables you to concentrate on writing your application while Bluemix handles most of the DevOps-y stuff like the networks, servers, storage, and software dependencies. It supports several programming languages, including Swift. It’s also easy to use - all you’ll need to manage your service is a web browser. You can even write your Swift code in your browser in the IBM Swift Sandbox.

This tutorial will take you over the basics of getting started with Kitura and Bluemix. First, we’ll set up Bluemix so we can upload our app and spin up a server with minimal effort when we’re ready. Then we’ll work through Swift Package Manager and Kitura step by step. Once some familiarity has been established, we’ll build something useful and upload it to Bluemix. We’ll build a small service that takes a cron expression and returns a human readable description of that expression, using the SwiftCron package from Swift Package Manager.

Setting up IBM Bluemix

To get started, head over to IBM BlueMix and sign up for a free 30 day trial. When you sign in you’ll be asked to name your organization, which is essentially your team that you can add other people to, and choose its location. Just choose the location that’s closest to you - the options are limited to where Bluemix currently has infrastructure set up. You’ll then be asked to set up a space, which is how Bluemix organizes apps and services.

You’ll then be navigated to the dashboard which is, understandably, empty. Click on Create App, and we’ll make things a little bit more lively.

Bluemix is built off of Cloud Foundry, which is an open-source Platform as a Service(PaaS). Bluemix then provides boilerplate for a few popular web frameworks like Python’s Flask framework to get you started instantly. Unfortunately, a boilerplate offering doesn’t yet exist for Swift, so we’ll be scrolling down past these enticing options to the Cloud Foundry Apps section. Choose Runtime for Swift.

Set your app’s name. I chose SwiftCronServer, and left the host name as the same auto populated value.

Only a few minutes in and we’re already cranking up a server. Wasn’t that easy?

Go back to the dashboard and you should be able to see your new app.

Click on it. Then, scroll down to the Continuous Delivery section and click on Enable.

You can deploy your code to Bluemix manually using a command-line interface, but it’s easier and more reliable to just push it upstream to Github and have it build automatically.

On the Continuous Delivery Toolchain page, scroll down to configurable integrations. Link your GitHub account, and then click on Create.

Getting Comfy with SPM and Kitura

Now it’s time to get a Kitura project running locally. Create a new folder for your project.

mkdir SwiftCronServer
cd SwiftCronServer

Both Kitura and the Cron library we’ll be using are available as packages through the Swift Package Manager, so we’ll create a new project using SPM with swift package init —type executable

There are four options for the type specification: empty, library, executable, and system-module.

empty has empty Sources and Tests folders, and a Package.swift with the package’s name set to ‘empty’
library has a Sources folder with a swift file named after the folder it was created in (hereafter referred to as the package name) with a struct named after the package. It also has some boilerplate set up for testing and a Package.swift with the package name
executable has a Sources folder containing a main.swift, an empty Tests folder, and a Package.swift with the package name
system-module creates a package.swift for you and a Clang module map

Great! Now let’s add Kitura and SwiftCron as dependencies in the Package.swift. Change your Package.swift file to look like this:

import PackageDescription

let package = Package(
    name: "SwiftCronServer",
    dependencies: [
        .Package(url: "https://github.com/IBM-Swift/Kitura.git", majorVersion: 1, minor: 2),
        .Package(url: "https://github.com/TheCodedSelf/SwiftCron.git", majorVersion: 0)
    ])

You should now be able to run swift build and Swift Package Manager will clone the packages listed in the dependency array as well as any dependencies that those packages contain.

Note:

If you have troubles getting the right tagged version of the dependencies listed in Package.swift, try the following:

If it’s your repository, make sure to push the tags of that dependency: git push —tag
If you’re certain the tag exists in the remote repository, but Swift Package Manager seems to be struggling to pick it up, delete the cloned repository to cause SPM to pull it again: rm -rf Packages/MyRepository-Version

Now we can run our project by typing .build/debug/SwiftCronServer into the terminal:

Now that we’ve got a Hello World SPM executable running, we’ve got three steps remaining:

Make it into a Kitura app
Integrate SwiftCron to make it a ‘useful’ Kitura app
Put the app on Bluemix

Start off by replacing the contents of main.swift with the following:

import Kitura

let router = Router()

router.get("/") {
    request, response, next in
    response.send("Hello, World!")
    next()
}

Kitura.addHTTPServer(onPort: 8090, with: router)

Kitura.run()

You can build and run the project again and open a web browser to http://localhost:8090/ to see the results. swift build .build/debug/SwiftCronServer

Building something useful

Now we’ll start using SwiftCron. Update main.swift to look like the following:

import Kitura
import SwiftCron

let router = Router()

router.get("/:cron") {
    request, response, next in
    defer {
        next()
    }

    guard let cronString = request.parameters["cron"],
        let cronExpression = SwiftCron.CronExpression(cronString: cronString) else {
            response.send("Invalid cron expression.")
            return
    }

    response.send(cronExpression.longDescription)
}

Kitura.addHTTPServer(onPort: 8090, with: router)

Kitura.run()

Let’s talk about what we’re doing:

let router = Router() Create a router object that we can configure with different paths.

router.get("/:cron”)

Look out for GET requests to the root URL with a parameter named ‘cron’

defer {
        next()
    }

next is a closure that tells Kitura to begin executing the next handler in the path if there are any. The defer block will always be executed at the end of the function regardless of the code path that is followed, making it a great place to put cleanup code.

guard let cronString = request.parameters["cron"],
        let cronExpression = SwiftCron.CronExpression(cronString: cronString) else {
            response.status(.badRequest).send("Invalid cron expression.")
            return
    }

Get the parameter that was passed into the get request, and create a cron expression with it. If the parameter doesn’t exist, or it’s invalid and a cron expression can’t be created, notify the user with a 400 response (bad request) and a description of the issue. Then return, firing off the defer block above.

response.status(.OK).send(cronExpression.longDescription)

If everything is working, send a 200 response (OK) with the human readable description of the cron string that was passed in.

Great! Build and run the project. In your browser, try call your Kitura server specifying a cron expression, for example, 0 12 * * * *:

http://localhost:8090/0%2012%20%20%20%20

Try another: 42 7 11 5 3 *

http://localhost:8090/42%207%2011%205%203%20*

Now that everything is working as expected, it’s time to move it off of localhost.

Putting it on the cloud

Clone the Github repository that was created while integrating Bluemix and Github. If you look in the Sources directory, you’ll see that things are a bit more complex. The starter app follows best practices that we’ll be using. Take a look at main.swift and you’ll see that there is no configuration of routes. main.swift handles logging and starting the server - that’s all it does, just as it should be. All the hard work is done in the Controller class which exposes a port and a router object for main.swift to start the Kitura server.

Add the SwiftCron package into the Package.swift: .Package(url: "https://github.com/TheCodedSelf/SwiftCron.git", majorVersion: 0. Now we’re able to duplicate the functionality that we had in the local project that we had running. In Controller.swift, import SwiftCron add the following to init():

router.get("/:cron", handler: getCron)

Now, in Controller.swift, create the getCron function with the same logic that we had in the local project. You’ll see the getHello and getJSON functions as examples of what we’re trying to do.

Declare a getCron function:

public func getCron(request: RouterRequest, response: RouterResponse, next: @escaping () -> Void) throws {
}

Add a log message at the top of the function:

Log.debug("GET - /:cron route handler…")

And a response header:

response.headers["Content-Type"] = "text/plain; charset=utf-8”

Implement the same functionality that you had in the local SwiftCronServer project so that you end up with the following request handler:

public func getCron(request: RouterRequest, response: RouterResponse, next: @escaping () -> Void) throws {
    defer {
        next()
    }

    Log.debug("GET - /:cron route handler...")
    response.headers["Content-Type"] = "text/plain; charset=utf-8"

    guard let cronString = request.parameters["cron"],
        let cronExpression = SwiftCron.CronExpression(cronString: cronString) else {
            response.status(.badRequest).send("Invalid cron expression.")
            return
    }

    response.status(.OK).send(cronExpression.longDescription)
}

Great. Your Controller.swift should look this example on Github: https://github.com/TheCodedSelf/SwiftCronServer-1482253378221/blob/0ef375dce8b18197faec29ebc9445b34cf354d90/Sources/Kitura-Starter/Controller.swift

Commit your code and push it. Your continuous delivery toolchain should build the app automatically. If it has any issues, hit the ‘restart’ button under Actions on the right.

Note: If you’re having any issues, such as the server crashing, you may want to tail the logs. The easiest way that I’ve found to do this is from the command line. Follow the ‘Getting Started’ instructions for deploying with the command line interface:

The most important steps to follow are the steps on the page to login to bluemix. Once you’ve got the CLI tools and you’ve logged in via the command line, do a cf logs MyAppName to receive any logging emitted by Bluemix as well as your app.

Now, access the route of your application. Mine was https://swiftcronserver.mybluemix.net/. Append a cron string to that URL to see your work in action (for example, 30 * * * * * would be https://swiftcronserver.mybluemix.net/30%20%20%20%20%20*).

Congratulations - A functioning and semi-useful Swift Server Side application.

Summary

We’ve learnt the following:

How to use Swift Package Manager
Basics of Kitura
Using Bluemix to effortlessly deploy Swift Server Side applications

Hopefully this knowledge will inspire you to use a new and exciting toolset to execute your next great idea. Have fun!

A Caution On Superfluous Code

2016-12-15T00:00:00+00:00

The line of code that the developer can write the fastest, the line of code that the developer can maintain the cheapest, and the line of code that never breaks for the user, is the line of code that the developer never had to write.

- Steve Jobs

Superfluous code is code that is written unnecessarily. It is code that has all the added complexity of valuable code, but it adds no value of its own. If you were to remove it, the product would behave exactly the same. I can think of a few causes of superfluous code:

Improper understanding of the toolset

If a developer doesn’t properly understand the language or the library that is being used, how can he be certain that the code he writes is suited to the task at hand? Oftentimes code is written that duplicates functionality included in the standard library. Now the same functionality exists in two different places: in your code base, and in your library. It has to be maintained twice. And tested twice.

For complex algorithms, you’re losing the benefit of years and years of bug fixes and performance improvements to the implementation that’s available to you through your toolset. Take the time to understand what is available to you. If it suits your needs, use it. Don’t write superfluous code when you can write no code and gain the same value from your platform’s SDKs. But, if you don’t know what is available to you, you’re doomed to repeat the bugs of the past.

I recently came across the following Swift code:

import Foundation

class Foo {
    var isRegisteredForNotifications = false
    
    init() {
        registerForNotifications()
    }
    
    func registerForNotifications() {
        isRegisteredForNotifications = true
        NotificationCenter.default.addObserver(forName:Notification.Name(rawValue:"MyNotification"),
               object:nil, queue:nil,
               usingBlock:notificationWasFired)
    }
    
    func notificationWasFired(notification: Notification) {
        /*
        .
        .
        */
    }
    
    deinit {
        if isRegisteredForNotifications {
            NotificationCenter.removeObserver(self)
        }
    }
}

NotificationCenter is a class in Swift’s Foundation library that implements the Observer pattern. You add an object as an observer for a particular notification and tell it what code to call when that notification is fired. The Foo class is registering for the MyNotification notification and asking NotificationCenter to call notificationWasFired when someone fires the notification.

The developer added a flag to the class which he sets to true when the notification is registered, and he then removes the instance as an observer in deinit, as one should. All good, but developers that have used NotificationCenter will know that removing an observer is a safe operation. For instance, one could do the following:

NotificationCenter.removeObserver(self)
NotificationCenter.removeObserver(self)
NotificationCenter.removeObserver(self)

Without any negative impact. It’s known that removing an observer is safe, even if the observer is not registered for any notifications. There’s no reason to include the overhead of the extra flag which has to be set, checked, and maintained.

Changing requirements

Requirements change as businesses evolve. It’s one of the reasons our jobs are so hard. Sometimes, you write code that was useful yesterday but it has no functionality today. It may no longer be called anywhere. Or you may be calling a function whose result is no longer used. If the function’s return value is never accessed, and the function produces no other side effects, why keep it? If you need it later, your source control will remember it.

False sense of safety

var factory = new WidgetFactory();
if (factory != null) {
	Console.WriteLine(factory.name);
} else {
	return;
}

var config = new WidgetConfiguration();
if (factory != null) {
	factory.createWidgetWithConfiguration(config);
}

Null checks are good. NullReferenceExceptions are bad. But is that second null check really necessary? If nothing is modifying factory, don’t check it twice. And if your application is a tangled ball of threads, and you have no idea if factory will still be a valid pointer at the time you need it, then maybe those race conditions are a more important problem to solve.

Premature optimization

Writing more performant code usually leads to less readable code. That’s why you’ll hear the advice time and time again that you should only optimize parts of the application that has proven to be a problem through the inspection of metrics. Any optimization that is done without the inspection of current performance should be seen as superfluous, as it does not satisfy any requirement of the application.

Why superfluous code is a problem

When you come across code like this, whether it’s fresh code in a pull request, or in a legacy class that you’re factoring, it’s your duty to remove it. Why?

It breaks convention.

There’s a superfluous null check before accessing variable foo. What about the other location where foo was accessed? What about when we access bar? What about other classes that access objects of the same type as foo? Was foo a special case? Or is this now best practice? Too many questions! Luckily, you can remove all ambiguity by removing the superfluous code.

Extra code means extra capacity for bugs

We need to write code because that’s how we build shippable features. Code adds value but more code means more complexity and more places things can go wrong. If the code you’re writing doesn’t add value or perform a necessary function, it only serves to increase the capacity for bugs.

The code that isn’t written has 100% test coverage, now and into the future

Someone might argue that the code is safe from bugs if it’s covered by tests. But is the code covered by the right tests? Have all possible permutations been covered? What about future changes? You can’t know about future changes. There can’t be any guarantee that the code will be tested six months from now. But I can guarantee you that 100% of the code that I didn’t write is still 100% tested.

Extra code means extra cognitive load

Open a class in your project. Any class. Now select everything in the body of the class and delete it. It’s much easier to understand something that’s empty. As we add more functionality to the class, there’s more that a reader needs to take in to fully understand that class. We are increasing the cognitive load when we add to the class, but it’s a small price to pay for the obvious gain: a (hopefully) valuable product. However, when you add superfluous code, you’re increasing the cognitive load without adding value. The class is now harder to read while providing zero extra gain.

Summary

More code means more complexity. More complexity means a heightened possibility for bugs, and more time to understand the intention of the code. Every time we add code we are making a tradeoff: more complexity for more value. I want the code that adds value. But if I’m making a tradeoff where I add complexity and gain no value, that’s not a deal that I want to be a part of.

P.S.

Thank you for listening to my ramblings on my first ever blog post. Please leave a comment or send me a mail at thecodedself@gmail.com with any feedback you have!

The Coded Self

Perfect is the Enemy of the Good

How the Wrong Architecture Can Cripple Development

We had the best tools

How does it work?

Technically…

In practice…

A better approach

Easier

Enabler

Don’t make me think

Getting there

The right tool for the job

Rule of Three

YAGNI

The result

Please share your thoughts

UI Testing the Clean Way

Just press record

Not as easy as we thought

Complicated setup

Duplicated code

Hard to read

A better approach

-Starting for setup

-Interacting for reusability

-Verifying for readability

Let’s get started!

Body of the test

1. Finding the delete button

2. Tapping on the button

3. Verify that the View screen is dismissed

4. Verify that the to-do is deleted

Wait a second…

Running code with StartupConfigurable

Tying it all together

What else can we do?

Please share your thoughts

Creating a macOS Action (Gear) Button Programmatically in Swift

Create an NSPopupButton

Position the button

Add some items

Add the gear icon

Style the cell

Autoresizing Masks and You

What the heck is an Autoresizing Mask?

Why does it cause conflicting constraints?

You probably won’t need the autoresizing mask.

Functions Deserve Injection, Too

The Problem

The Solution

Please Share Your Thoughts

Staying Sane with Cuckoo and Code Generation

Then, I was introduced to Cuckoo.

Code Generation versus Reflection

Using Cuckoo without going nuts

Get comfortable with ParameterMatchers

Run the script before compiling your tests

Break down unclear compilation errors

Call verify last, not first

If you can’t beat them, exclude them

Use it when it makes sense

Lessons learned from Systems Thinking

A quick definition

It’s not the fault of the person. It’s the system.

The performance of an organisation depends on the quality of systems, not of individuals.

Problems faced by an organisation can most likely be solved by a system.

A high frequency of software defects

Underskilled developers

The same bugs occurring repeatedly

Boundaries are flexible.

Fix the problem, not the symptom.

A final thought

iOS: Animating your own toast view

Animating a drop down view from the navigation bar

Animating the transform

1.

2.

3.

4.