Concept Confetti

Work & life have been busy lately, but I wanted to share some links I found enlightening across tech & social justice topics:

Learn about how Apple’s M1 chips work.

Time: 11 Moments From Asian American History That You Should Know

Lego Replay - give new life to bricks you don’t use anymore.

Git reflog & rewriting git history

Tiffany Alvoid on Eliminating Microaggressions: The Next Level of Inclusion | TEDxOakland - 2019

High level discussion of systemic racism in the tattoo industry.

And lastly, how to toggle showing hidden files on a Mac: 

Having dealt with concurrency and data synchronization issues in the past, I’m always interested to hear how other folks approach that problem set. With that in mind I checked out Swift by Sundell Episode #95 “Concurrency orchestration” with special guest Brent Simmons. I usually keep these notes in order of the discussion in the podcast, but I’ve reorganized this time to keep related topics together. 

~~~~~~~~~~

Concurrency

You usually want to be pushing background work onto a serial queue.

Want to stay on main thread unless there’s a really solid reason not to. Write it the ideal way. If you see a blocker, use profiler and see what’s the root cause.

Identify things that need to go in the background and make them self contained (example rss parsing, parsing data and turning into model object). During parsing you shouldn’t be doing anything that could affect the rest of the app. Put the work on a serial queue and callback on the main thread.

The fact that something is on a background thread should not leak. Send the operation to the background queue, then callback at the end. Don’t have the background thread sending notifications or doing other things that leak knowledge that it is background work.

Threading leads to so much uncertainty and problems. Reducing areas of moving back & forth makes your code more resilient.

Try giving structure

Going from main to background to another background can be okay, but consider treating it as a stack and moving data back up rather than cutting straight back to a previous queue/main queue.

Thread safety

Sharing mutable data across threads is setting self up for crashes or data inconsistencies

Databases

serial queue for reads & writes that calls back onto main queue

Keeps changes ordered

Always calling back on main thread

Apple tends to callback on thread work performed on.

URLSession does work on background then calls your callback also on background.

Can lead to data races, or calling UI APIs from background threads.

Need to look out for these and make sure UI work is going back on main queue.

Can write code such that you accept a callback queue but have it default to main so you can choose a different queue if necessary.

Performance problems on main thread

Many developers tend to drop to work to background threads before profiling to know where the issue is coming from.

Not everything can be solved with concurrency. The problem might manifest as a lot time in a function, but a background thread might be a bandaid rather than solving the issue.

Senior developers

Role is to find simpler solutions, find the simplest way to create a performant experience, not complicated code.

Brent Simmons project - NetNewsWire

Open source project. 

Originally Mac only (project started pre-iPhone). Rewritten in 2014. 

Created version of the app using SwiftUI & combine only, did not ship since performance wasn’t where they wanted things to be, but held onto that code. 

They are using a couple pieces of SwiftUI in shipping app, but mostly waiting to fully shift over to SwiftUI

Mac vs phone SwiftUIMac performance noticeably less than on iPhone. large reason chose not to switch over to SwiftUI after investing time was degraded performance on Mac

Anyone can join the open source development of net news wire:

Check the app out

Check out the GitHub

Join the slack group and “work” channel

Talk about what you’re interested in building or ask for a bug to work on

Concurrency for NetNewsWire

objects are never mutable on main

Has a single background queue for database operations

Status objects (read/starred) is reference object created & mutated on a background serial queue

Any thread can say to update the “read” status, but that “read” status is only ever updated on the one synchronized queue.

Reflection

How are you handling threads in your project?

Does your background work callback on background or main?

Is your background thread sending notifications or other things that leak background status?

The following google features/suggestions are all from the article 20 Tips to Google Search Efficiently. I’ve listed the items I rarely or never use below as a reminder to start incorporating them.

 ~~~~~~~~~~

!! Hyphen to exclude words !!

-Java

Never use this and can be very helpful if differentiating between similarly named things from different frameworks/languages

Colon to search specific sites

I find it’s less that I don’t use this and more that I search & let google surface the specific site link for me if there are multiple results on a single site (often stack overflow =p).

!! Finding a page that links to another page !!

Link:<URL>

Enabled by how google traverses the web with spiders. Use case: Want to know who cites/links to a particular article?

Asterisk wild card

Use cases: Looking for song lyrics but you forget a word? Know most of the syntax for a command but forgot a parameter?

!! Surface sites similar to a specific site !!

Related:Amazon.com

Will return results for other online stores

Search using multiple terms

Use OR operator, helps narrow results by being able to compare against both

!! Searching a range of numbers !!

Uses .. operator with either a number on the right for single date, or number on each side for a range to search

Limited use cases but very helpful for those specific applications.

Search by filetype

Filetype:pdf

I’m trying to branch out on resources and took a listen to the “Swift Unwrapped” podcast episode 86 “Tuples”, available on most podcast providers and online.

~~~~~~~~~~

Difficulties using in arrays when want to pass to things conforming to organization protocols

No conformance to codable, equitable, hashable

No elegant solution found yet

Interestingly c++ tuples are equitable but not hashable

Limit of 12 items in a tuple 

more than you should ever need

Having non-nominal type with 12 members over named struct? Not preferable

 What is threshold for stopping & creating named type?

4-5, slap a name on that bad boy

Public APIs returning tuples 

Too hard to use generally 

Can’t extend that

Documentation

Being unnamed makes them unwieldy to refer to in conversation & documentation

Not suited for public api use, but nice for a structure for a subset of an algorithm

Once you start crossing data boundaries with a tuple it begins to lose its power

Can add labels, but at that point, would a struct be more appropriate?

You Can name the members of a tuple when you create it

Adding labels means autocomplete will only show the labels but you can still refer to them by index 

In swift can have very locally scoped nominal types

Gives a nearly anonymous named struct or class

It’s rare that a tuple can give you new powers that a strategically placed struct would not

It’s Easier to add a member to a struct than a tuple

Can’t have a tuple with no elements, can have a struct with no members

Need to provide a unique hashable identifier: You can create an instance of hashable empty struct and every other instance of that struct will match, but nothing else will. Gives type safety because there’s no way even if named same something can give the same identifier.

Performance concerns using struct over tuple?

Minor size diffs of name and debug I do for a struct vs tuple, but that’s nearly insignificant for most applications

Tuple might not be able to be bit packed the same way as structs for size optimization

Order is important in both structures

Tuples with different labels don’t impact equality or hashability

Can compare 2 tuples with same value types but different label names

Issues of not having a type, if using tuples and have a 3D point tuple and an rgb color space tuple swift would let us compare them even though that makes no sense to do

If it’s important to define semantics of a type that matches the type signature of another, name it!

Cannot treat tuples like collections (think array  protocols)

C fixed length arrays imported as tuples in swift

But do we want to add more complexity to something that should be rarely used?

Today I want to share some links I liked!

Red Hat: What is Kubernetes?

I’ve known vaguely what Kubernetes is for a while, but lacked specifics of where and how it fits into a system. The Red Hat “What is Kubernetes?” doc is a bit long, but an incredible reference for anyone wanting a basic overview. Their glossary of domain-specific terms and diagram of the components of Kubernetes really helped the concepts come together for me.

Autistic Hoya Blog: Ableist Words and Terms to Avoid

In my first departure from coding topics here, I listened to an episode of Brené Brown’s Podcast “Dare to Lead”. This ep Brené with Aiko Bethea on Inclusivity at Work: The Heart of Hard Conversations can be found online or on Spotify

~~~~~~~~~~

You can’t have diversity without inclusion. You can collect a bunch of folks from different backgrounds, but if they don’t feel like they have a place there or are made to feel othered, it isn’t inclusive.

Transactional vs transformative change

compliance vs feeling personal need to pursue change

Transactional only trying to change culture creates a lot of shaming and blaming and core numbers over actual togetherness

Putting pressures on people without them understanding why

Require connection and empathy

Changing culture is more than numbers, you have to make changes within the people who make up that culture for it to be truly transformative 

Big barriers are seeing yourself or community differently

it’s not just that you aren’t “sucking it up”

There’s shame and grief that needs to be faced rather than putting on more armor

What are you learning about yourself

Have to challenge things about yourself that there’s no rewards or pats on the back for

Armor is not rewarded or required - you need vulnerability to search and move forward.

Expectation of talking about issues and wanting to hear folks’ experiences because it’s “urgent”.

It was already urgent for folks who have been impacted by this day to day well before George Floyd.

Who are we serving by doing this work and how

Recognizing the privilege of just now saying “we need to be talking about this” and the added impact for affected people now being expected to talk about these topics.

Are you doing DEI work to benefit marginalized folks or to tick boxes for your company?

Centering of white timing

Work should co-lead by marginalized groups 

Action bias, pacing, are these benefiting impacted folks?

Horizon conflict

Conflict over different concerns, timing, urgency even if goals are shared

Taking diff responsibilities for diff horizons

Action bias

Need to fix and fix fast

Driven by discomfort & vulnerability. We feel these things and rush to solve even before the problem has been truly defined

Slow down. Listen. - As opposed to rushing for a solution and applying your sense of urgency as an act of privilege.

Getting to place of believing someone not automated when you have completely different lived experiences. When listening to folks stories, if you feel any hesitation, ask yourself:

 “Why would I not believe this?”

“What does it mean about me that I didn’t see this?”

Transformative change requires introspection which takes time. Deep seated issues cannot be simply solved in a single action or set of prescribed actions.

When listening to experiences

Think about your power & privilege and how you can use it

Hold off on the instinct to immediately fix

Ask questions, really understand the problem and the pain behind it 

Before trying to fix a situation yourself, involve the impacted person. 

Ask “What does support look like for you in this situation?”, “How can I empower and support you to handle it yourself if you want to?”. 

This week I wanted to learn more about SwiftUI and dove into “Swift by Sundell” podcast episode 91 "Is SwiftUI ready for production?” with guest David Smith, available on most podcast providers and online.

~~~~~~~~~~

It isn’t a question of “Is SwiftUI ready?”, but “Is your app able to take advantage of it?”

Working with SwiftUI

Parts that aren’t great:

Some layouts are hard to do

Usually when model bleeding into view, or views that are distant siblings that need to know about each other

Look to redesign to make them parent child or find a diff solution

If you find yourself thinking about using the preferences system probably want to take a different approach

Can be tricky to make separate view the same height/width

Trade off of investment vs productivity - guest is finding it a net win on time to get UIs built

Live changes vs build & run very impactful

Customization of Components

Can be hard to customize built-in components like a list. How do you approach? Is there a concern changes to work around will cause breaks?

You have slightly less control than in UIKit

Embrace default behavior - easier to maintain, will behave more closer to how users will expect based on components similar to it 

If need to make a custom component, break it down into atomic SwiftUI views

Try to not implement uikit in same views because leads to brittle code. Avoid mixing code in a way apple isn’t testing and can’t guarantee will continue to work how you expect

If you need complete fine grain control, SwiftUI may not be the right tool

Getting to a place where it’s a bit more like web design you can’t make assumptions about window size or text size - just like we cannot at this point make assumptions about screen size or text size and need layouts that can handle variation.

Data Management and Movement

What are good ways to model complicated set ups i.e. Sharing data and constructing view hierarchies?

State needs to be shared between views

Guest: A lot of singletons - shared observable object that are for a particular domain. On change updates anyone subscribed to that domain.

Reading from external data sources into an object and view just needs to pull from that object for updates

Think of redux style shared data store - singleton of state that’s subscribed to for changes

Build hierarchies that each manage a piece of that shared state, try to scope them so they don’t leak to places they aren’t necessary 

Try to have leaf nodes used used on the hierarchy not aware of the state objects instead having them passed data by their parents. 

Screens vs views - screen is aware of data source and unwraps optionals and passes data to the views - That way can experiment with cases by passing data to views in preview.

Only put things in the environment object that are truly global, think about the app level - Something like an image loader you use everywhere could be in environment. 

Interoperability 

Are for putting SwiftUI into uikit project but not moving the other way

Try to give SwiftUI the simplest Lay-out possible

If resizing needs to happen (such as for text), try pushing that to SwiftUI 

Lets you do changes piece by piece and experiment before moving completely to SwiftUI

This blog is for me to dump notes on things I’m learning or working on. It’ll mostly be notes on development topics from podcasts/books/articles but may occasionally contain some crafting stuff.

This week’s bunch-o bullet points comes courtesy of the “Swift by Sundell” podcast episode 93 Combine & Core Data with guest Donny Wals, available on most podcast providers and online.

~~~~~~~~~~

General development

Drawing out design beforehand, even just the connecting pieces to understand reliances.

Writing test cases out first, help think through edge cases first.

Combine

Released with SwiftUI.

Try to look at building blocks of combine & rules for them. If you find yourself fighting with the restrictions, consider if combine IS ideal for the problem.

It is not an operation queue or a futures & promises library and will fall short of expectations as a replacement.

Episode guest Donny Wals has a book “Practical Combine”.

Keeping combine pipeline simple

(How do you balance pipeline being a wrapper for a closure vs all combine operators?)

Define operators to group work for a single task, created in extensions. Then you can reuse for your common workflows (think Filter that removes nil elements from publisher - probably want to do that in more than one location). Operations become more atomic and more easily testable in isolation.

If you’re trying to implement custom publisher, consider using a subject instead.

Testing with combine

Using collect to get events omitted by publisher.

Using expectations to check values after running.

Can specify number of items you want to collect - very helpful for publishers that do not complete.

See the Show notes for implementation of await for publishers.

Core Data

Core data is not a database, it’s a graph management system.

Until iOS 10 Core data was difficult to set up, with NS persistent container apple simplified the set up process.

Thread Safety

Core data managed objects are not thread safe, you cannot grab on a background thread and throw into the view

Not being thread safe causes issues for many folks because it does not crash by default when this happens. It may work fine for a while - until it does not.

Threads and queues are not the same thing - you might have 2 queues working on the same thread and core data seems to be fine, but if one queue moves to a new thread it may suddenly break.

Tips on using core data

To help prevent threading issues, move access to managed objects into a perform block. Perform block takes a closure and runs the contents on the appropriate queue for that managed context.

Using child contexts for intermediate changes if you want to keep original context clean until committing changes -as opposed to a local struct, duplicating code (think about case where your managed object is a model, would need to duplicate code for that model if wanted to use an intermediate struct).

User defaults used to need to be told to save, now save happens almost immediately.

Core Data migration

Migrations are painful.

Create new model version every time you make changes.

Core data will handle adding new field, renaming a field on new version