Most of these guidelines are to match Apple's documentation and community-accepted best practices. Some are derived some personal preference. This document aims to set a standard way of doing things so everyone can do things the same way. If there is something you are not particularly fond of, it is encouraged to do it anyway to be consistent with everyone else.
This document is mainly targeted toward iOS development, but definitely applies to Mac as well.
NSString *foo = @"bar";
When working with Git, there are two prevailing workflows are Git workflow and feature branches. IMHO, being more of a subscriber to continuous integration, I feel that the feature branch workflow is better suited, and the focus of this article.
If you are new to Git and Git-workflows, I suggest reading the atlassian.com Git Workflow article in addition to this as there is more detail there than presented here.
I admit, using Bash in the command line with the standard configuration leaves a bit to be desired when it comes to awareness of state. A tool that I suggest using follows these instructions on setting up GIT Bash autocompletion. This tool will assist you to better visualize the state of a branc
To remove a submodule you need to:
| # first: | |
| lsbom -f -l -s -pf /var/db/receipts/org.nodejs.pkg.bom | while read f; do sudo rm /usr/local/${f}; done | |
| sudo rm -rf /usr/local/lib/node /usr/local/lib/node_modules /var/db/receipts/org.nodejs.* | |
| # To recap, the best way (I've found) to completely uninstall node + npm is to do the following: | |
| # go to /usr/local/lib and delete any node and node_modules | |
| cd /usr/local/lib | |
| sudo rm -rf node* |
| // | |
| // UIView+Orientation.h | |
| // | |
| #import <UIKit/UIKit.h> | |
| // These macros should only be used if you MUST know the interface orientation for the device itself, for example when displaying a new UIWindow. | |
| // This should be very rare; generally you should only look at the immediate parent view's size (or "view orientation" using the category below). | |
| #define StatusBarOrientationIsPortrait UIInterfaceOrientationIsPortrait([[UIApplication sharedApplication] statusBarOrientation]) | |
| #define StatusBarOrientationIsLandscape UIInterfaceOrientationIsLandscape([[UIApplication sharedApplication] statusBarOrientation]) |
| //`UITableViewCell` and `UICollectionViewCell` are `Reusable` by defaut | |
| //Use the extension method to dequeue an instance of the appropriate `Reusable` | |
| class MyVC: UITableViewDataSource { | |
| override func viewDidLoad() { | |
| super.viewDidLoad() | |
| tableView | |
| .registerReusable(FooCell.self) | |
| .registerReusable(BarCell.self) | |
| } |
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,
In Swift there's a message in "Test Target" that states that the bridging header will be removed in newer versions of swift. I'm using mixed objc and swift clasess, but the UnitTest class is a swift file. Using @testable key was there in code
@testable import YourProject
You fix it by adding in your Test area the bridging header with objc headers that your test will use: