bitrise (https://www.bitrise.io) is the best that I've used so far for building iOS apps. Its elite package is also really fast if you can afford it. I've used travis (slow, 45 min build times) and gitlab-ci with a dedicated mac pro runner and bitrise wins hands down for speed and simplicity. Also don't forget fastlane (https://fastlane.tools). Most of my build configuration is in fastlane (for iOS and Android) and bitrise just triggers fastlane via the script step. Good luck!
You could try Flow (https://flow.org) as you're already familiar with JavaScript. I've been using it after primarily using static languages and it's been great so far.
I'll assume this isn't a joke and that you just aren't well versed in computer science nor in database theory. While Postgres doesn't use distributed consensus it does use distributed transactions to maintain consistency (a major tenet of ACID compliance).
In a distributed consensus environment a substantial number of proofs of work (in Bitcoins case a hash) must be performed to gradually ensure that a block in the chain is consistent and thus come to a consensus that it is in fact valid.
In Postgres a transaction can be verified and guaranteed to be consistent among nodes using a two phase commit protocol. Essentially a transaction is attempted, verified, and then committed by the nodes of the network in a guaranteed, and very secure, manner.
The upside to the Postgres method is you do not need a substantial number of individual processors to perform proof of work to securely verify consistency.
Yes it's more cognitive overhead but it's a more functional than imperative style which usually has many advantages. If the functions are named well (naming being the hardest problem) then it should be easy to read without knowing exactly what the implementation of the function does.
I agree that you can split validation parts into separate functions but this is conflating two concerns, for example the rewriting of the guard statement from
if count == 0 {
throw VendingMachineError.OutOfStock
}
only proves that you can refactor the code to not use guard whereas the article starts by talking about small functions, where you could in fact still use guard in this case.
Yes. And if all your code is composed of three-lines methods, then ok. Otherwise guard is extremely usefull, because unlike 'if' it leaves your constant/variable accessible outside the guard scope.
Yeah you're right. If you want to stick with value types and store those values in an Array where the array can only store one type then you have to use an Enum instead of classes. I think there are a few people getting confused by not identifying enums in Swift as a more powerful construct than in C/ObjC.
And with associated values in enum types they behave in a similar way to case classes in Scala that extend a sealed trait.
For example I've been working on a Json library that stores everything in an enum (ADT):
public enum JsValue {
case JsString(String)
case JsNumber(Double)
case JsObject([String: JsValue])
case JsArray([JsValue])
case JsBoolean(Bool)
case JsNull
}
Well, yes. But that wasn't what I was talking about.
Trait objects in Rust let you emulate inheritance. The issue I was talking about is that folks from inheritance-heavy languages use this as the de facto design pattern, and then stuff doesn't work so well, because you're not supposed to use inheritance so much (the languages aren't designed with this in mind). The correct option is to use enums and composition over inheritance wherever possible.
In functional languages, functionality should be extrinsic (case match values from the outside), while in OO languages like functionality is intrinsic (polymorphic method members called on the value). However, for things like hashing, intrinsic works way better (hence traits, protocols, type classes, and so on).
Saying use composition over inheritance "wherever possible" can lead to some cargo culting on its own. It is always possible to use composition over inheritance, but it isn't always wise.
