Skip to content

Instantly share code, notes, and snippets.

View mmertsock's full-sized avatar
💭
⛰️ 🐐

Mike Mertsock mmertsock

💭
⛰️ 🐐
View GitHub Profile
Your goals are to reduce the number of things that you have to keep in your head at any given moment, and to rely as little as possible on your own ability to consistently do things right.
If you make a thing immutable ('let' in swift), you never have to think about what happens if it changes, or what other parts of the code you'll effect if you change it.
If you split complex functions into several smaller functions that only interact by passing arguments or getting return values, then you limit the amount of code you need to consider when hunting for a bug, and you can test each small piece separately.
If you understand what things must be true in your code (aka invariants, for example "a person's age must be greater than 0"), and either provide no function that can cause them to be untrue, or check and crash immediately when they're untrue, then you don't have to debug issues caused by incorrect assumptions.
If you remove possibilities (for example, Swift removes the possibility of things being nil unless
@tclementdev
tclementdev / libdispatch-efficiency-tips.md
Last active June 7, 2024 17:41
Making efficient use of the libdispatch (GCD)

libdispatch efficiency tips

The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).

My take-aways are:

  • You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.

  • Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse

@DreamingInBinary
DreamingInBinary / Best in Class iOS Checklist
Last active January 29, 2024 18:18
This is a public checklist updated every year after the latest version of iOS and iPadOS are shipped. It's a boiled down version of a "Best in Class" app checklist created by Jordan Morgan.
# A Best in Class Checklist
A boiled down checklist adapted from this [post](https://www.swiftjectivec.com/a-best-in-class-app/), created by @jordanmorgan10.
> To use this, create a Github Issue in your own repo, and simply copy and paste this text.
## iOS Core Technology
_Things any iOS app can benefit from_
- [ ] iCloud Sync
- [ ] Focus Filter Support
@marco79cgn
marco79cgn / sonos-nowPlaying.js
Last active January 6, 2024 07:46
A scriptable widget that shows what's playing on SONOS
// Variables used by Scriptable.
// These must be at the very top of the file. Do not edit.
// icon-color: cyan; icon-glyph: magic;
// the node sonos http api base url (running on your Pi for example)
let sonosBaseUrl = "http://192.168.178.10:5005"
// optional for cover art: the ip address of one of your Sonos speakers
let sonosPlayerUrl = "http://192.168.178.38:1400"
let param = args.widgetParameter