| // Douglas Hill, November 2019 | |
| // Find the latest version of this file at https://github.com/douglashill/KeyboardKit | |
| import UIKit | |
| /// A scroll view that allows scrolling using a hardware keyboard like `NSScrollView`. | |
| /// Supports arrow keys, option + arrow keys, command + arrow keys, space bar, page up, page down, home and end. | |
| /// Limitations: | |
| /// - Paging scroll views (isPagingEnabled = true) are not supported yet. | |
| /// - The scroll view must become its own delegate so setting the delegate is not supported yet. |
| // Douglas Hill, December 2018 | |
| // Made for https://douglashill.co/reading-app/ | |
| // Find the latest version of this file at https://github.com/douglashill/KeyboardKit | |
| import UIKit | |
| /// A table view that allows navigation and selection using a hardware keyboard. | |
| /// Only supports a single section. | |
| class KeyboardTableView: UITableView { | |
| // These properties may be set or overridden to provide discoverability titles for key commands. |
Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.
This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,
| <?xml version="1.0" encoding="utf-8"?> | |
| <!-- | |
| Copyright (C) 2015 The Android Open Source Project | |
| Licensed under the Apache License, Version 2.0 (the "License"); | |
| you may not use this file except in compliance with the License. | |
| You may obtain a copy of the License at | |
| http://www.apache.org/licenses/LICENSE-2.0 |
| apply plugin: 'com.android.application' | |
| android { | |
| compileSdkVersion 21 | |
| buildToolsVersion "21.1.2" | |
| defaultConfig{ | |
| minSdkVersion 14 | |
| targetSdkVersion 21 | |
| versionCode 101 |
| /* | |
| * Copyright (C) 2014 I.C.N.H GmbH | |
| * | |
| * Licensed under the Apache License, Version 2.0 (the "License"); | |
| * you may not use this file except in compliance with the License. | |
| * You may obtain a copy of the License at | |
| * | |
| * http://www.apache.org/licenses/LICENSE-2.0 | |
| * | |
| * Unless required by applicable law or agreed to in writing, software |