DivineDominion

#!/usr/bin/env ruby

# Avoid all the script configuration and use this convenience script instead!
#
# 1) Put it into the same folder,
# 2) run the script: `ruby _execute.rb PATH/TO/THE_NOTE.txt`


##################
# Configure here #

DivineDominion

Keybase proof

I hereby claim:

• I am divinedominion on github.
• I am ctietze (https://keybase.io/ctietze) on keybase.
• I have a public key ASAeEXhO_3ukmYArB4BCULSfFFT-rpg6j_aXiWWv_zmBEwo

To claim this, I am signing this object:

DivineDominion

Affect the order/priority of subscription callbacks in ReSwift

(Reply to "Any way to control the priority of subscription callbacks?" ReSwift/ReSwift#404)

ReSwift does not guarantee any subscription callback order. Since ReSwift uses an unordered Set as its subscription store, there's no reliable way to know when a subscription is invoked.

This implementation detail is hidden by design. If you find yourself wanting to affect the order of subscription callbacks, there's a concept of a sequence waiting to be extracted somehow.

These are the ways out:

DivineDominion

import Cocoa
import RxSwift
import RxCocoa

@NSApplicationMain
class AppDelegate: NSObject, NSApplicationDelegate {

    @IBOutlet weak var window: NSWindow!

    let disposeBag = DisposeBag()

DivineDominion

// - MARK: Example Code

/// A model 
struct User {
    let firstName: String
    let lastName: String
    let age: Int?
}

/// Initializer using a Partial<T> -- You could generate this with Sourcery

DivineDominion

struct Foo: ExpressibleByBooleanLiteral {
    var value: Bool
    init(booleanLiteral value: BooleanLiteralType) {
        self.value = value
    }
}

func ==(lhs: Foo, rhs: Foo) -> Bool {
    return lhs.value == rhs.value
}

DivineDominion

Title: Focus ReSwift reducers to one state change ID: 201801041611 Tags: #reswift #srp

ReSwift reducers should not have conditional side-effects, changing different states out of convenience. That makes it hard to notice which action changed what. The condition is most of the problem, I think.

An ideal approach would be to have 1 reducer/action pair for each substate change.

When reducers overlap (they touch the same state), this can become a problem. (IncreaseCounter and DecreaseCounter are a bad example.) Conditional changes to another substate should be extracted as another action which is dispatched by a Middleware under similar circumstances.

DivineDominion

#!/usr/bin/env ruby

require 'optparse'

CURRENT_PATH = File.expand_path(File.dirname(__FILE__))
FALLBACK_PATH = File.join(CURRENT_PATH, "..", "build-xcode", "Debug", "include", "libMultiMarkdown", "libMultiMarkdown.h")

options = {:mode => :nsenum}
OptionParser.new do |parser|
  parser.banner = "Usage: #{$0} [options] path/to/libMultiMarkdown.h"

DivineDominion

//
// Based on: https://blog.beecomedigital.com/2015/06/27/developing-a-filesystemwatcher-for-os-x-by-using-fsevents-with-swift-2/
//

import Foundation

public struct Event: CustomStringConvertible {

    public let eventId: FSEventStreamEventId
    public let eventPath: String

DivineDominion

class ModalDialogController: NSWindowController {

    convenience init() {

        self.init(windowNibName: "ModalDialogController")
    }

    @IBOutlet var closeButton: NSButton!

    override func windowDidLoad() {