JaviSoto

#!/bin/bash

set -e
trap "exit;" SIGINT SIGTERM

unset TOOLCHAINS

ALIAS=mxcl
VERSION="3.0.0-${ALIAS}+$(date +%Y%m%d)"
PREFIX="$HOME/Library/Developer/Toolchains"

JaviSoto

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 

JaviSoto

• You can find the article published here: http://www.javiersoto.me/post/106875422394
• For questions, it's also available on Github: https://github.com/JaviSoto/Blog-Posts/blob/master/Functor%20and%20Monad%20in%20Swift/FunctorAndMonad.md

JaviSoto

struct Set<T: AnyObject> : Printable {
    typealias ElementType = (T: AnyObject)

    var set: NSMutableSet

    init() {
        self.init(array: [] )
    }

    init(array: ElementType[]) {

JaviSoto

#!/bin/bash

# https://gist.github.com/949831
# http://blog.carbonfive.com/2011/05/04/automated-ad-hoc-builds-using-xcode-4/

# command line OTA distribution references and examples
# http://nachbaur.com/blog/how-to-automate-your-iphone-app-builds-with-hudson
# http://nachbaur.com/blog/building-ios-apps-for-over-the-air-adhoc-distribution
# http://blog.octo.com/en/automating-over-the-air-deployment-for-iphone/
# http://www.neat.io/posts/2010/10/27/automated-ota-ios-app-distribution.html

JaviSoto

Keybase proof

I hereby claim:

• I am javisoto on github.
• I am javisoto (https://keybase.io/javisoto) on keybase.
• I have a public key whose fingerprint is A401 6A03 CA78 5463 EF54 B0B1 4196 06D9 0B5A BAFD

To claim this, I am signing this object:

JaviSoto

- (void)tapIntoViewControllerWillAppear {
  @weakify(self);
  [[[[[[[RACSignal interval:0.1f onScheduler:[RACScheduler mainThreadScheduler]] takeUntil:self.rac_willDeallocSignal] flattenMap:^RACStream *(id value) {
    @strongify(self);
    
    return [RACSignal return:self.pb_viewController];
  }] ignore:nil] take:1] flattenMap:^RACStream *(UIViewController *viewController) {
    return [viewController rac_signalForSelector:@selector(viewWillAppear:)];
  }] subscribeNext:^(id x) {
    @strongify(self);

JaviSoto

ReactiveCocoa

A lot is being written these days about ReactiveCocoa and the paradigms it introduces. In my opinion, there are only two sides giving their opinion: the ones that know a lot about it and are therefore obviously biased, and the ones that refuse to learn it.

I decided to write something myself because I think I'm right in the middle. Some months ago I knew nothing about it, and now I know enough to want to use it every day. I hope that by not being an expert, I can actual introduce a few really simple ideas in a much easier way to pick up by new-commers, to show why I think ReactiveCocoa is an incredibly powerful tool to help us write better, cleaner, and more maintainable code.

It's signals all the way down

The base of everything that happens in ReactiveCocoa is signals. I'm going to try to explain what they represent and why they fit in the way we think about what happens on an app. A lot of the things you may read about Functional Reactive Programming end up confusing you when

JaviSoto

#import <ReactiveCocoa/RACQueueScheduler+Subclass.h>

/**
 * This scheduler class schedules values sent down a signal on the main thread synchronously 
 * if they're sent on the main thread as opposed to RACScheduler.mainThreadScheduler 
 * which always sends values asynchronously.
 */
@interface PBMainThreadSynchronousScheduler : RACQueueScheduler

+ (instancetype)mainThreadSynchronousScheduler;

JaviSoto

@interface JSObjectBytesDataDecorator : NSData

+ (instancetype)dataDecoratorWithData:(NSData *)data holdingOnToBytesOfObject:(id)object;

@end