Considering SwiftUI, now I see how much wasted time was spent on intense discussions about things like, should you pass your model object to your UITableCell subclass to set its properties?

#WWDC2019 So. Much. New. Shiny. My. Head. Exploding.

Kurzgesagt is one of my favourite things on Youtube. “The Side Effects of Vaccines - How High is the Risk?” youtu.be/zBkVCpbNn…

Top Tier CoreAnimation Tip in this WWDC2014 preso developer.apple.com/videos/pl… and ronnqvi.st/multiple-… Commit a change to a layer property, and also animate from the difference to 0 with additive = true. Smooth. (New to me anyway :))

No one warned me that being a contract software developer, also means schlepping equipment up a mountain…

Even more Axiiio field testing; this time in the old convict settlement ruins near Port Gregory, Western Australia

mp-photo-alt[]=mp-photo-alt[]=

Some Axiiio field testing while in a camping trip. Getting a motion time lapse of the sunset.

Garnet grains on a beach near Kalbarri, Western Australia. Looked like a dusting of pink sugar across the beach.

Jumping on the immutable state bandwagon (with a nod to Redux) in an iOS app, suddenly opens up a bunch of opportunities for testing. I can save and load an app’s state to/from a file, which is super handy.

Well this is annoying. Same Swift code literal is correctly CGFloat outside of an array, but within the array it’s an Int… !? Also the 1.0 on the next line becomes a Double, :slaps_forhead:.

It’s only when you’re sharing code between platforms that you discover things like on iOS char is signed, but on 32bit ARM systems like Teensy 3.x char is unsigned. My brain is exploding trying to understand the consequences.

Working out of Axiiio labs this week. Working with embedded devices is a whole new world from working on a big software stack. Lots of fun though.

The new Xcode lldb v command seems a lot faster, but at first try I don’t think it can see type extensions. po sees the method in my class extension but v doesn’t?

Whoa… if you know Objective-C, you’ll appreciate this method name I just found in UIFoundation:

-[NSCoreTypesetter _NSFastDrawString:length:attributes:paragraphStyle:typesetterBehavior:lineBreakMode:rect:padding:cgContext:baselineRendering:usesFontLeading:usesScreenFont:scrollable:syncAlignment:mirrored:boundingRectPointer:baselineOffsetPointer:wantsTextLineFragments:applicationFrameworkContext:]

Hooray for Swift 5! Immediately had a use for the new Result type.

Xcode upgrade, Swift 5 migration went surprisingly well. All I had to do was upgrade carthage and build the project, no changes required. Lovely when that happens.

This is Apple admitting their previous CoreData examples were rubbish:

“Previously in iOS, the Core Data stack was typically initialized within the application delegate. However, doing so causes a significant amount of code to get muddled in with application life cycle events.”

My son said to me the other day he wonders why when there are so many companies selling content why business models are only ever ads or subscriptions… good point!

Cleaning out old cupboards and drawers is like suburban archeology. For example, in a drawer filled with junk I found 5 hole punches. I think I can draw a pretty accurate conclusion that we’ve had the need to punch holes in paper approximately 5 times in the last 10 years.

Woo! published my first CocoaPod: Shawshank. A small but nifty Swift unit test framework for stubbing network calls. github.com/atetlaw/s…

#SurryHills

Dim Gaggle of UberbEats riders outside Chur burger all bikes, backpacks, and impatience

Muted terraces signaling to huddled pedestrians outrunning the rain finding sporadic shelter under the Sober trees

Love in the time of unit testing

Here’s the text of a lightning-talk I gave at the beginning of 2016 at one of SafetyCulture’s Townsville company gatherings. I really liked it and thought I should share it here for posterity.

My talk today is on Unit Testing, kind of a boring topic I realise.

In the world of iOS unit testing doesn’t come naturally, It’s uncommon to find an iOS engineer with lots of unit testing experience. And yet every iOS developer here who has given it a go, has been amazed and how much it helps them. when writing new code.

There’s a gap

So i’m wondering about that gap between the unit testing the chore and the epiphany of how helpful unit testing is. And this is my crack at bridging the gap.

Too much focus on what and how

I notice that when I talk about unit testing generally I always focus on the what and the how. What to test, what shouldn’t be in a unit test, how to test classes that have dependancies, how to mock objects and things like HTTP requests.

Much complaining

And mostly complaining about how the unit tests are always failing, needing maintenance, are out of date, or test very little.

Unit testing is a chore

How they take too long to write, or how, once automated testing is running, no one can merge a PR until all tests pass. Because I think that’s what happens when you focus on the what and the how. Unit tests become a chore.

You didn’t estimate enough time

It’s not a part of the programming you’re doing, it’s the bit you tack onto the end, that you didn’t estimate enough time for. Unit tests are a hassle, a pain in the arse, a velocity-sapping, slog.

Why even unit test

The what and how tend to get entangled in procedure. it gets in the way of working out why your even doing it. Other than I have to write some and they have to pass to get my PR merged.

I think if you truely understand why you’re writing unit tests, all the rest follows. All the things you want to put in a test, all the ways you want to test it all become easier through the lens of knowing why.

It’s not all about you

And sure unit testing is helpful while you’re writing new code. Writing or refactoring code in a complex app can be terrifying. Adding tests along the way helps you make sure you’re on the right track, spot edge cases and so on sure.

But it’s not all about you!

Do it for love

Most defects are introduced during coding, but the least number of defects are found during coding. There’s only one reason to write unit tests, the only reason that matters.

You have to do it for love.

Don’t worry, I got your back

Unit tests are a declaration of love for your fellow engineers. They say I care about you, man, and the work you’re about to do. Don’t worry I got your back.

Unit tests are a declaration of love for the product. Unit tests are a declaration of love for SafetyCulture. What happens when you have love in your unit tests?

See it from the other engineers’ perspective

You start to think differently about your code , you start to see it from the other engineers’ perspective. You think about how to make it more testable, you think about all the possible states your code can get into.

You think about how someone else might approach using your API. You write your tests in a way that demonstrate how it should work, how it can fail, what can go wrong when it does.

Tripping balls

You can demonstrate how your code will behave in a positive state, a negative state, and a tripping-balls-what-hell-is-going-on state.

You haven’t broken anything

When you go to work on a codebase with love in its unit tests you know you can rely on them to show you how it’s all supposed to work and reassure you that you haven’t broken anything.

Your team is behind you

You can bravely take on those big refactoring jobs, knowing your team is behind you all the way. Once you know why your writing those unit tests, it guides you on the implementation.

The next engineer

You worry about the time it takes to run: you want to make sure the next engineer can run them as often as they need to feel secure.

Avoid fragile tests

You avoid writing fragile tests that rely on timing, on application state, or UI state – anything that could randomly fail if conditions aren’t right – because that creates confusion, and uncertainty.

And you care that the engineer running your tests is not left confounded, wondering why the tests are failing 10% of the time.

Mock or stub only when necessary

You use mocking or stubbing only for what’s necessary, because overuse ties the unit tests too much to the implementation details of mocked classes. You don’t want to make your mate rewrite all your tests because some unrelated implementation detail has changed.

Avoid persistent state changes

You avoid making persistent state changes you don’t want your unit tests leaving behind a mess someone else has to clean up.

Be descriptive

You make sure to be as descriptive as you can about what’s going on in your tests and why the expected output is legit.

Test something useful

You make sure your tests actually test something useful.

Write tests for humans not robots

Your avoid torturing your code (by breaking it into smaller and smaller parts until it’s perfectly testable, all dependancies are explicit, code coverage is very high, but understandability is very low) because you know you’re writing tests for you fellow human engineers, not writing tests for robots to run.

Even though we might automate them.

Write tests with love

You write tests with love, because you’re not writing them for yourself, You’re writing them for the next engineer, because you care that they succeed.

Inevitably, 6 months down the track, that next engineer turns out to be you. And you can say, thanks past me, you’re weren’t such a jerk after all.

Here it is: boardgamegeek.com/boardgame…

So many evil cats! Played Root for the first time. Really good fun. Each player has different rules, but somehow it all works magically.

Currently experimenting with CoreLocation and extending types to provide Measurement values: gist.github.com/atetlaw/0…