大概几个月前，受题叶影响开始关注函数式编程，在看完一本 js 的函数式之后，对函数式有了点基本的了解。

函数式给我的感觉，最大的一个主旨是是编程中所有过程可控，尤其在 js 这种没有原则的语言中，过程可控制有为重要。

函数式

到底什么是函数式，他和命令式编程和面向对象有什么区别。（知乎上已经有很多讨论了，感兴趣的话，我在结尾的地方贴了一些链接。）
总的来说，在函数式中，函数是一等公民，函数能作为变量的值，函数可以是另一个函数的参数，函数可以返回另一个函数等等。

函数式中有些个人感觉比较有意思的点

纯函数

最喜欢纯函数了，什么是纯函数呢？纯函数有三个重要的点：

1. 函数的结果只受函数参数影响。
2. 函数内部不使用能被外部函数影响的变量。
3. 函数的结果不影响外部变量。

这有什么好处呢？当你有一堆函数对某个数据进行操作的时候，就能轻松定位到哪些函数出了问题，这也就是 Redux 的中心思想，控制状态的 Reducer 就是一个纯函数。

不可变

说到纯函数，不得不聊聊不可变。

FB 在推出 React 之后， immutable.js 也跟着火起来了。不可变，顾名思义，就是变量或者结构在定义之后不能再发生值的变动，所有操作只是产生新的值而不是去覆盖之前的变量。这样去控制数据，能够让数据流动更加可控。

流

在 jQuery 大行其道的代码中，最为人称赞的莫过于其链式操作了，但不知道有没有人跟我一样遇到过一些问题，比如我对一个节点进行操作，搞着搞着当前节点不是这个节点了，当我需要对这个节点再进行一次操作的时候，只能新开一个链式。

在函数中，流永远只是对当前的那个初始的数据进行操作，而且当加上惰性链，所有过程更加容易控制。

什么是惰性链？

回想一下 jq 的链式操作，是不是每次一个链接加上去就立马生效，当你写完一堆链式之后，发现不对，如果不能一眼看出是哪步错了，只能一次次去删最后的操作来找原因。而惰性链是在你写完链式时候并不会执行，而是在最后跟上一个执行用的函数，才会去执行前面的所有函数。

mixins

打个比方，当我们需要类型判断的时候，红皮书里一般都是各种 if，不知道平时写的时候也是这样，用个 utils 写各种类型判断的函数，然后挨个 if。

用 mixins 思路的话，大概可以这么去做：

dispach(
function(s){ return isString(s) ? s : undefined },
function(s){ return isArray(s) ? stringifyArray(s) : undefined },
function(s){ return isObject(s) ? stringfyObject(s) : undefined },
function(s){ return s.toString() }
)

这样只要有个函数返回的肯定是字符串了。

函数响应式编程

响应式编程（反应式编程）

响应式编程是一种面向数据流和变化传播的编程范式，数据更新是相关联的。比如很多时候，在写界面的时候，我们需要对事件做处理，伴随着前端事件的增多，对于事件的处理愈发需要更加方便的处理。

设想一下，平时在处理事件的时候，一单上了复杂度，比如输入的时候，需要停止输入的时候才进行，这个时候又只能输入长度大于2才进行事件，当还是之前的数据的话不进行事件，可以考虑一下这个情况下如何去写。

拿 RxJs 中的一端例子举例

var keyup = Rx.Observable.fromEvent($input, 'keyup')
      .map(function (e) {
        return e.target.value; 
      })
      .filter(function (text) {
        return text.length > 2; 
      })
      .debounce(750)
      .distinctUntilChanged(); 

是否十分简洁。

把函数范式里的一套思路和响应式编程合起来就是函数响应式编程。

不知道有没有发现其实 Promise 也是响应式编程的一种。

举个寒冬大大的代码，在一个按钮上绑定两个事件，一个是 5s 后触发，一个是用户点击。

function wait(duration){
    return new Promise(function(resolve, reject) {
        setTimeout(resolve,duration);
    })
}

function waitFor(element,event,useCapture){
    return new Promise(function(resolve, reject) {
        element.addEventListener(event,function listener(event){
            resolve(event)
            this.removeEventListener(event, listener, useCapture);
        },useCapture)
    })
}

var btn = document.getElementById('button');
Promise.race([wait(5000), waitFor(btn, click)]).then(function(){
    console.log('run!')
})

把两个事件绑定到按钮上，这两个事件函数同时也是 promise，这样只要有一个触发了就会执行，相比普通代码

btn.addEventListener(event, eventHandler, false);
setTimeout(eventHandler, 5000);
function eventHandler(){
  console.log('run!');
}

当需要增加更多事件组合的时候，更加容易拓展。

刚才的代码，用 Rx.js 实现会更加简洁

var btn = document.getElementById('button');
var logRun = Rx.Observable.fromEvent(btn, 'click')
             .merge(Rx.Observable.timer(3000))
             .subscribe(e => {
               console.log('run!');
               logRun.dispose(); // 如果是一次性的就移除observable
             });

先这样，若有不对的地方请告知，感谢～

概念

原先搭建这套东西其实没多少事，但是受人邀请，还是写篇文章防止后来人踏坑吧。

持续集成系统（CI）想必看文章的应该都知道是什么东西，应该都清楚，如果不太明白的，移步 https://en.wikipedia.org/wiki/Continuous_integration

总结起来其实也很简单： 把构建和发布的问题自动化、简单化。

你可以想象这么一个场景：

当你的代码写完后，敲入一个git push，CI 系统自动帮你compile/test/archive/publish 而你只需要坐在那边，喝一杯java就够了。

对于爱“偷懒”的程序员来说，这是十分惬意的事情，因为我们最自豪的就是解放自己的生产力，让自己不要花时间去做一些无意义的事情，既伤神又费力。

安装Gitlab

当然，在当今的时代，我们拥有docker这种神器，其实安装这件事情，也已经很傻瓜化了。

OK，那么简单几行命令搞定

docker pull gitlab/gitlab-ce
docker run -d -P gitlab/gitlab-ce      

如果需要进行端口映射，请参考-p参数

当你配置好之后，访问你的母鸡地址，出现这个页面就是部署好了，然后就是注册和登陆的事情。

安装Gitlab CI Runner

Gitlab最新版中已经将CI系统内置了，所以我们只需要部署runner即可。runner是啥概念？因为我们的CI在跑的时候，不应该被它的安装环境所限制，比如我们把CI安装在linux下，这时候想打包iOS可能就办不到了，所以Gitlab CI就把整个 CI 拆成两个部分，一个server和一个runner，如今server也都内置到Gitlab里去了，所以安装好了就好了。

那么我们可以在一台 Mac 上安装好runner连上Gitlab即可。

https://gitlab.com/gitlab-org/gitlab-ci-multi-runner

这个传送门是到gitlab-ci-multi-runner的，上面有介绍了如何安装使用runner。但是要注意的是，它一般都会在linux环境下使用的比较多，而在windows和OS X下好像并没有，这也是为什么我这次踩坑的原因了。

首先，我们下载好gitlab-ci-multi-runner的二进制文件，我们知道要把它做成服务的话，需要以下步骤：

• register

• install

• start

register就是告诉server 这个runner的存在，install是安装成系统服务，start就是启动服务啦~ 这3个命令很简单。

那么，我们先执行gitlab-ci-multi-runner的run看，它是不安装系统服务，直接跑的命令。

好嘛，一来就发现刺眼的3个warning，对，就是这3个warning把我带入了深渊。 它的意思很明确，要求我们用root身份执行这个命令。

但是！！ root是不能在Xcode archive 完之后 进行codesign的！即时你在gitlab-ci-multi-runner指定了 --user 也不行！！

所以，我们在这里要做的就是无视这3个warning，转而用我们自己用户的身份进行安装服务

gitlab-ci-multi-runner install --config xxxx -d /tmp
gitlab-ci-multi-runner start

即可，-d是指定runner的工作目录，也就是把代码库clone下来的目录，我指定到了/tmp文件夹。

使用 xcodebuild 和 xctool

xcodebuild 就是 Xcode 的命令行工具能提供 编译/测试/打包 等功能，我们只需要指定workspace和scheme或者project即可编译，指定好Provisioning Profile等证书文件就能打包，但是它的输出非常不好看，这次我们使用了xctool 这个工具，它是facebook开发的，用来美化xcodebuild输出的一个辅助工具，个人很喜欢它的输出样式。

安装xctool也很简单：

brew install xctool

来一个使用xctool的样例：

xctool -workspace SegmentFault.xcworkspace  -scheme $PRERELEASE_SCHEME archive -archivePath ./build/SegmentFault.xcarchive

这里我们指定了workspace和scheme（我用环境变量代替），然后指定了导出xcarchive中间格式的路径，那么我们导出成xcarchive就完成了，如果要导出成IPA，需要这个中间产物。

导出IPA

然后导出IPA，我们使用xcodebuild命令：

xcodebuild -exportArchive -archivePath ./build/SegmentFault.xcarchive -exportPath ./build -exportOptionsPlist ./ExportOptions.plist CODE_SIGN_IDENTITY="$CODE_SIGN_IDENTITY" PROVISIONING_PROFILE="$PROVISIONING_PROFILE"

ExportOptions.plist里面指定了一些选项，比如导出的环境（AppStore/AdHoc/Developer等），其实就是我们在Xcode/Origanizer中配置到的那些：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>compileBitcode</key>
    <false/>
    <key>method</key>
    <string>ad-hoc</string>
</dict>
</plist>

执行完xcodebuild 就得到了我们的ipa文件，如果是手工敲命令的话，就是这么几个步骤。

集成到Gitlab

那么如何让CI跑这些命令呢？这时候我们就需要使用Gitlab CI中的.gitlab.yml这个文件了，Gitlab只要检测到有这个文件，就会开始构建你的项目，具体的使用说明可以看这里：http://docs.gitlab.com/ce/ci/yaml/README.html

那么贴一个我的样例

variables:
    PRERELEASE_SCHEME: "SegmentFault_Alpha"
    CODE_SIGN_IDENTITY: "xxxxxx"
    PROVISIONING_PROFILE: "xxxxx"
    LANG: "en_US.UTF-8"

stages:
  - archive
  - upload

archive:
    stage: archive
    script:
        - pod install
        - carthage update --platform iOS
        - xctool -workspace SegmentFault.xcworkspace  -scheme $PRERELEASE_SCHEME archive -archivePath ./build/SegmentFault.xcarchive
        - "xcodebuild -exportArchive -archivePath ./build/SegmentFault.xcarchive -exportPath ./build -exportOptionsPlist ./ExportOptions.plist CODE_SIGN_IDENTITY=\"$CODE_SIGN_IDENTITY\" PROVISIONING_PROFILE=\"$PROVISIONING_PROFILE\""
    only:
        - fir
    artifacts:
        expire_in: '1 day'
        paths:
            - ./build/$PRERELEASE_SCHEME.ipa
upload:
    stage: upload
    only:
        - fir
    script:
        - fir publish -T xxxxxx -c ./CHANGELOG ./build/$PRERELEASE_SCHEME.ipa
    dependencies:
        - archive

这里我们看到stages总共做了2个任务archive和upload，我在archive的定义中，执行了4条命令，分别是pod相关，carthage相关，然后是xcodebuild相关命令进行打包，iOS程序员应该都知道pod和carthage吧，是在打包前给我们安装依赖的，依赖安装好了才能构建，这是常识。

在这个步骤完成之后，我们执行upload任务，就是调用fir-cli这个工具，把我们的应用发布到fir.im上，给测试人员分发测试。

结语

好了，我终于从在Xcode中进行打包，导出后到fir.im上进行上传ipa操作，并写Change Log任务这么一系列很繁琐的工作中解脱了，以后我就只需在fir这个分支上进行一次push，那么所有的工作就都做完了，这就是CI的魅力。

赶紧试试吧~

当初我买MacBook Air的时候特地选择了高配版本，硬盘空间是128G（2011年的古董机器），在最开始的1-2年内使用还不错，后来发现越来越力不从心，为了尽可能腾出空间，几乎把所有的照片、视频和PDF文档都移到了云上，也经常用CleanMyMac等工具进行清理，但还是发现空间被一些已经卸载的App蚕食，既然没有更好的方案，那就自己写一个工具来清理吧。

前几节内容是比较繁琐的技术介绍，不感兴趣的同学可以直接跳到工具的使用那一节

App最喜欢的几个目录

Mac和Windows操作系统有一个很大的不同，大部分App是没有安装程序的，一般下载下来就是一个dmg文件，解开之后直接将App拖到应用程序目录下就可以了，所以给人感觉卸载也就是将App拖到废纸篓然后清空。如果真这样做就大错特错，即使一个最简单的App都会在下面几个目录中或多或少留下纪念，这些目录一般有：

• ~/Library

• ~/Library/Application Support

• ~/Library/Application Support/CrashReporter

• ~/Library/Caches

• ~/Library/Containers

• ~/Library/LaunchAgents

• ~/Library/Preferences

• ~/Library/PreferencePanes

如果一个程序是通过pkg方式安装，或者是在第一次运行时请求管理员权限，那一般还会在如下几个目录中留点纪念：

• /Library

• /Library/Application Support

• /Library/Extensions

• /Library/LaunchAgents

• /Library/LaunchDaemons

• /Library/PreferencePanes

• /Library/Preferences

以上都还是只是列出了部分，不同的App由于需要还会在其他目录中安装一些文件，比如字处理软件一般会在/Library/Fonts下面安装字体，有些扩展组件会放在/Library/ScriptingAdditions下面。

限于篇幅，我不能一一介绍所有目录的内容，选几个重点的目录大概说一下：

~/Library/Application Support

这个目录可以说是App最重要的文件目录，一些App本身并不大，但是需要的支持组件和内容非常多，特别是采用第三方插件和缓存网络内容的软件，例如我用的Dash，本身的大小只有24MB左右，但是由于经常浏览资料，所以缓存了很多网络内容，使得它的Support目录达到了1.37GB！可想而知，如果只是将App扔到废纸篓，几乎不会节省任何空间。

~/Library/Preferences

这个目录下保存的是App设置，一般来说，稍微有点规模的软件都有自己的配置信息，放在这里的文件虽然占空间不多，但是清理掉还是有好处的，例如有些App不能正常工作，即使卸载重装也不行，往往就是配置文件出错了，把这里清理掉之后再重装就会有比较好的效果。

~/Library/Containers

这个目录对于App Store上下载的软件来说，是最重要的一个目录，由于Apple的限制，AppStore的软件都在沙箱中运行，每个软件在沙箱都有自己的一个完整空间，对于App来说，它以为自己在一个正常的目录系统中运行，但实际上不是，操作系统重定位了读写位置到沙箱之中。
要是卸载软件的时候，只是简单的在Launchpad中点一下叉来删除，那不知道又有多少空间莫名其妙地消失了，我曾经用这种方式卸载了网易云音乐，结果后来才发现，整整417MB的空间不见了……

~/Library/LaunchAgents

Mac上的随机启动方式之一，熟悉OS X操作系统的同学应该立刻想到了launchctl，这里就是存放启动配置文件的地方，大部分App只会往这里写启动信息，请神容易送神难，要送神，只有用第三方工具或是自己手动清理了，还有，LaunchAgents 和 LaunchDaemons 是有一些区别的，两者虽然都是随机启动，详细对比请看LaunchAgents VS LaunchDaemons

本工具的概述

直到现在我还在想，要是用Cocoa来写这个工具的话，程序会小很多，现在这个程序压缩包有40+MB，其实绝大部分都是Electron、React的框架库，真正的代码也就几个文件，加起来不到1M大小。而之所以选择用JavaScript来做，其实就是想验证一下React开发一个桌面应用到底会怎样，JavaScript是不是有一统江湖的本事？

用JavaScript最大的顾虑也许是性能问题，程序虽然难度不大，也有几个运算比较密集的地方，一是plist信息的解析，二是正则表达式。我将plist解析放到外部库去做了，正则表达式仍然用Google的V8引擎，目前来看还行。

程序的I/O比较多，需要频繁统计文件占用空间大小，查找相关文件，读取文件信息，虽然JavaScript的最大好处是异步操作，但是在统计出结果之前，界面能做出再多的响应也没有什么意义，因此在有些地方，我没有使用异步操作，要是你感觉界面有点卡，那是我的原因，不是React的错:)

再给大家推荐一下Mac系统上自带的AppleScript，这个是Mac上的瑞士军刀，能和Windows上的Powershell有得一比，我在这个软件中最后的清理工作实质上就是通过AppleScript来完成的，例如清理工作首先要关闭目标程序，你要是自己编程打算怎样实现？枚举系统进程然后kill？用AppleScript就能非常优雅地完成，例如你打开Safari，再同时开一个终端窗口，然后在终端中输入

osascript -e 'quit app "safari"' 

名字的来由

来自于同名电影《Total Recall》，奎德在一次虚拟体验之后，突然发现自己原来不是一个默默无闻的工人，而是一个超级特工，那自己到底是什么呢？也许真正的自己永远也找不回来了，但是至少不是现在这样浑浑噩噩。

我也想借这个意思表示即使通过努力清理，也不一定能还原到最初的状态，但至少不会这么糟糕。

工具的使用

这个好像没有什么太多可以说的了，我只是对比了和CleanMyMac的清理效果，至少，在大部分情况下，我感觉还不错。

卸载百度云的对比

可以清楚地看到，CleanMyMac没有找到百度云的Application Support目录，此外，只找到了登录项，没有找到启动项和启动文件。

Total Recall不仅找到了CleanMyMac所有的内容，还找到了Application Support，这里有1.14MB空间，此外还找到了LaunchDeamons里面的启动项和启动文件，还发现了com.baidu.netdiskmac.BDYunFinderInstaller这么一个鬼……

比较一下卸载AppStore上的App

CleanMyMac列出了一大堆感觉挺吓人的，仔细看才发现其实都是Containers\com.tencent.xinWeChat这个目录里面的子目录，还拿一个系统临时目录来充数（电脑重启后系统临时目录都会清空），卸载的时候其实只要删除沙箱目录就万事大吉。

存在的不足

• 有一类软件是以Package方式发布的，里面有复杂的安装步骤，例如Microsoft Office 2016 for Mac这样的，对于这类软件，需要分析的内容比较多，打算在完善后将Package卸载整合

• 软件界面很简陋，一是不大会玩CSS和HTML布局，二是初次使用React，前端高手可以指点我一下?

参考内容

• 《深入解析MAC OS X & IOS操作系统》 这本书对于想了解Mac系统的人来说是不二之选，值得拥有

• Information Property List Key Reference App里最重要的文件Info.plist的介绍，开发必备

• Electron 如果打算用Electron构建一个桌面App，必须从这里开始

• React React的官方网站，虽然我的界面做得挺难看，那是因为我还不怎么会玩css

• Total Recall 这……

Github 相信已经成为家喻户晓的代码托管工具, 但访问了多位周围编程爱好者后发现, 对其的使用还仅限于 下载项目源码 和 备份项目源码 的程度, 今天我就来介绍一下一个比较重要的使用场景 贡献代码

以 swoole 为例:

Fork 项目

• 首先需要fork这个项目, 进入项目页面, 点击右上角的Fork按钮
• 你的 github 帐号中会出现 swoole/swoole-src 这个项目
• 在本地电脑(Linux)上使用以下命令: 得到一个 swoole-src 文件夹

git clone git@github.com:samt42/swoole-src.git 

获取原项目代码

• 进入 swoole-src 文件夹, 添加 swoole 的远程地址

git remote add upstream https://github.com/swoole/swoole-src.git

• 获取 swoole 最新源码

git pull upstream master

现在我们在 fork 来的 master 分支上, 这个 master 留作跟踪 upstream 的远程代码...

创建分支

• 好了, 现在可以开始贡献我们的代码了
  按照国际惯例, 我们一般不在 master 上提交新代码, 而需要为新增的功能或者fixbug建立新分支, 再合并到 master 上, 使用以下代码创建分支

  git checkout -b branch1
  

  现在我们可以在分支上更改代码了

• 假设我们已经添加了一些代码, 提交到代码库

  git commit -a -m "new commit"
  

合并修改

• 一个常见的问题是远程的 upstream (swoole/swoole-src) 有了新的更新, 从而会导致我们提交的 Pull Request 时会导致冲突, 因此我们可以在提交前先把远程其他开发者的commit和我们的commit合并.

• 使用以下代码切换到 master 分支:

  git checkout master
  

• 使用以下代码拉出远程的最新代码:

  git pull upstream master
  

• 切换回 branch1:

  git checkout branch1
  

  > 如果忘记自己之前建的分支名可以用 `git branch` 查看
  

• 把 master 的 commit 合并到 branch1:

  git rebase master
  

• 把更新代码提交到自己的 branch1 中:

  git push origin branch1
  

Pull Request

• 提交 Pull Request
  你可以在你的 github 代码仓库页面切换到 branches 页面点击 branch1 分支后点击 New pull request 按钮, 添加相关注释后提交.
  OR
  切换到 branch1 分支的代码仓库点击 Compare & pull request 按钮, 添加相关注释后提交.

原文地址

我想分享一些文章，来帮你学习redux的概念和架构

在开始redux之前我们先来看这两篇文章，用High Order Components代替mixin和Smart & Dumb Components

然后 我们通过一个代码教程（我翻译地址）深入了解Redux，然后看一看 Redux & React超级介绍 完成你对reudux的探索之旅

现在是时候去学习 How to Bundle your Redux application 和 Avoid the Bad & the Ugly

再往前走:理解Redux Middleware 并且看一看 关于redux的一切.

注：尽量中文地址的我用的中文地址代替源地址，，