@happya 匿名性？这个跟区块链不是很相关。区块链的优势在于不可篡改(共识机制)，区块你当成一个只能 insert 不能 update 和 delete 的分布式数据库，在整个 p2p 网络大部分人的见证下写入成功。所以留痕后数据是永久存在，可以被拿来认证的。

金融领域各个行业监管机构比如证监会，可以率领各大券商形成一个行业链(联盟链)，然后通过智能合约的技术将若干需要签署 /留痕 /归档等业务集成在区块服务里，比如将你一笔基金的购买留痕写入区块链中永久的存起来，事后无法抵赖。在信用这方面同样也有很多类似的玩法。

至于交易，我个人不是很看好(毕竟这是一套效率奇低的系统)。

不懂就多读书，区块链本身综合了计算机科学，经济学与密码学三个领域的知识，而且作者在这三个领域都有想当的理解和高度(所以中本聪曾被质疑并不是一个真人，可能是一个组织)。

至于在金融领域，对监管的意义大一些：合规留痕，智能合约。

@iugo https://www.youtube.com/watch?v=v1CmGbOGb2I&t=3052s ←_←

@SlipStupig git 也可以走 http 账号密码的形式，形如 git clone https://username:[email protected]/group/project 反正 dockerfile 在你本地也不担心密码泄露。

不过这种场景有些别扭：Image 作为交付的承载，理应在 gitlab 提交时候自己触发远程机器或跟它同一个域负责构建机器上的 CI 构建过程。最后你本地 pull 下来直接用 Image

@xingda920813 you are right，第一点，就我的体会来说，kotlin 直接 copy 来官方的构建模板很顺滑，而 scala 数次没有折腾成功就弃了，所以没太展开。感谢补充

有人提到很疑惑 kotlin 和 scala 的区别，作为一个双修且两个语言都有上过准生产环境的经历(感谢开明又帅气的 boss)，简单说说我的浅显理解:
1. kotlin 运行时相对轻量，标准库逻辑不多。这主要体现出二者在实现思路上的显著差别，kotlin 一切尽可能复用 Java 已有的逻辑和实现，不少 API 仅仅是 Java 版本的封装。而 scala 则是一切都自己来一套。得益于此 kotlin 获得了与 Java 强大的交互性，kt 文件可以跟 Java 文件混写在一个工程(与 scala 不同的一点在于，kotlin 甚至不用以大目录区分)，并在 Intellij 大法的加成下，拥有无语伦比的开发体验。
这一点也或多或少体现在工具链上，kotlin 可以与 maven/gradle 无缝交互，而 scala 的官方构建工具 sbt 有一定上手难度，再加上众所周知的原因，从 sbt 的安装到工程导入伊始便会遇到层层阻碍，私以为这一点极大地阻碍了 scala 在国内的推广。

2. 在 Functional Programming 支持层面，二者均支持 first-class function/high-order function, Closure, Algebraic Data Type, Type Inference 尾递归优化等在静态语言里如果想舒爽的使用 FP Style 所必须的元素. 相比于 scala, kotlin 还欠缺 Pattern matching, Lazy evaluation 等特性，不过当前的程度已经足够令我满意。和 golang 这种欠缺类型多态的语言相比，kotlin 与 scala 都可以将很多副作用(Nullable，Either，Throwable，IO)直接 encode 进入类型系统，并通过类型系统直接表达和保证对这些副作用的正确处理。相关的 TypeClass/Monad 类库推荐 https://github.com/MarioAriasC/funKTionale 类比 scala 社区比较流行的 scalaz 和 cats.

3. 开源社区的亲和力与推广，Jetbrains 在营销和推广方面显然是个经验丰富的老司机，合纵连横多点开花收获了 Spring, Eclipse(Vert.x)等多个在 Java 领域举足轻重的大型社区官方支持。至于跟 Google Android 团队的关系也早在 Google 启用 Android Studio 作为 official support IDE 时算起便暧昧起来了。另一边，scala 社区背后的 Typesafe 公司(现在更名为 Lightbend)则曾对 Spring 抛来的橄榄枝不理不睬，保持一副高冷作风(e.g. 于 2012 年烂尾的 spring-scala 项目)。毕竟那边也有自己一套 Akka, Play, Lagom 等有自己玩法的技术栈，不亦乐乎。

4. 兼容性，算是一把双刃剑，可以扩大占有份额，也是创新前行路上的镣铐。kotlin 当前版本的字节码是 jdk 1.6 的规范（即使 kotlin 1.1 在编译期给定-jvm-target 1.8 开关，生成的字节码也仍然没有利用 invokedynamic, default method ）。另一点，同样也得益于小体积的标准库，在 Android 平台面对 APP 体积与 65535 方法数限制时，足以游刃有余。scala 从 2.12 起只能运行在 jdk 1.8 上面。

5. 创新与野心：2008 年横空出世的 scala 带来很多创新点，收获了极大地关注度，以至于倒逼促成了 jdk 1.8 的若干语法改动(stream API, optional, lambda)。kotlin 相对于 scala 或一众现代高级语言来说，更多的是取其精华且有所舍弃(比如 implict 这种相对复杂且显著拖慢 compiler 的特性) 并且吸收了其他领域语言的特性(比如 Delegated properties 应该是借鉴自 Objc 的 KVO?) 增强语言在移动平台的表达力。这一头 scala-native 这种玩票性质的工程多年还没什么进展，而另一头 Jetbrains 已经招兵买马组织了一波独立团队去并行研发 kotlin-native, 我内心还是很希望 Jetbrains 能把主要精力聚焦到 be a better Java, 至于 better c++这种事情完全可以交给 Rust 去折腾。

6. 学习成本，综合前面几点，尤其是第一点，kotlin 当前版本（ 1.1.2 ）几乎是处于没有标准库的阶段，对于一个 Java 熟手来说，简单通读一遍官网的语法规范即可上手。而随着后期 kotlin 其他标准库的补全和语法 /关键字的丰富(coroutine 协程 API 将于 1.2 版本彻底稳定，而剑指 Functional Programming 的 immutable collections 也正在紧锣密鼓的研发中)，后面学习起来会遭遇更多的信息和心智负担。考虑到实用性和上手速度，对这两门语言都感兴趣的话，我建议（先）学习 kotlin，而且是立刻和马上学起。

有感而发加上闲得慌，一不小心写成了长文，希望对有兴趣想尝试的小伙伴们有些许帮助。

@dawniii 1.2 之后实现的，这种方式弊端是方法不能被内联，否则还是不能让出时间片。

最近重构一个 python2+twisted 的项目，感觉 qps 也就 300 左右，很忧伤。。

有人对 twisted tornado node.js 写的 restful 的 benchmark 比例有个大概了解么？

优先 orm 吧 复杂的话着重优化建模，性能敏感场景再裸写 sql

redux-saga +1

redux-thunk 和 promise 都改变了 Action 的语义，不推荐

理解“服务编排”这个概念，跑一下 docker-compose 工具的官网 demo 就都明白了

@only0jac docker 的镜像是带 tag 的， tag 尾部是版本号。完全可以每次 git 提交都自动构建一个不同版本号的镜像（不可变运维）。至于性能，对服务器没附加要求，因为 docker 容器 run 起来后本质就是个宿主机的进程。有余力的话可以先深入了解下， segmentfault 站上面讲用容器技术 CI/CD 的例子还是很多的，与 gitlab 等的 CI 打通都是很容易的事情。

目前最好的方式是 docker ，私以为 docker 最大的优点是颠覆研发流程中的交付环节。编写 Dockerfile ，在 CI 环节编译打包工程，通过 dockerfile 来就地构建镜像（把编译产物与静态文件 copy 到镜像中是 Dockerfile 应描述的职责），最后将 image push 到公有私有仓库中。

容器启动就是一瞬间，秒级的。

评估是监管要求。真想开的话随意，客户经理巴不得多个客户呢

今天同事也遇到这情况

不能，管理学中对于一个抱团的小团体是忌惮的

Razer Abyssus 09 年就在用 用到现在，除了滚轮有点声音别的还是完美；后来买了个绿灯 13 版公司用

我也感觉是换网件