问题5 –须藤忍者–中

卡兰

1.实用距离表达式

在做验证的时候常常需要距离表达式的帮忙，但有时候case都做不完整，这个网站提供了很多范例！

2.nodejs 6.0版本

Nodejs 6.0正式发布了，官方宣布已经可以支持大部分的es6语法，但感觉…应该会有很多npm套件都会有冲突吧！先等一阵子稳定之后再升级吧！话说最近的节点怎么一直不断升级。

3.js文件系统

虽然js文件系统已经不是新玩意，但毕竟有任何跟随跟其他套件的帮助，一直以来也没有深入这一块。偶然之间想起，查了一下google，这篇文章写得还挺清楚的。呼，是该了解更进阶的的js了！

亨利

1. Docker上的Jenkins 2.0

很多团队都不敢贸然在开发流程中引入Docker，一个很大的原因是很多服务都还没有针对Docker做过最佳化。2015年Docker大流行时，网路上也出现了不少质疑Docker将服务虚拟化化之后随之而来的性能指标。但持该论点的文章，大多都是采用短时间，高并发的基准测试（套一句行话来说就是“烧机”式的测试）去测试Docker的性能，而不是真的让MySQL在生产环境上运行然后慢慢调整性能。但说实在地，声称测试的架构，谁又有这么大颗的心脏敢放它在生产环境上运行呢？

扯太远了。此周主要是发现Jenkins 2.0在Docker上执行的效能比1.x来说有非常显著的改善。由于目前Sudo是使用CircleCI做CI，还没有做CD，但在正式引入CD之前我预想到了一个问题。

CircleCI的IP不固定，要怎么样在兼顾AWS Security Group政策的替代下执行CD？

我目前想到的最合理的替代方案是直接在AWS内建立自己的CI / CD环境（至于如何架设还需要再研究，因为最终目的是一台EC2都不要管，全部改用ECS），而Jenkins正是但自行测试一次Jenkins 1.x之后，不是安装插件时让系统的load飙高到连壳都卡住的地步，不然就是正式建置专案时记忆体被塞爆（在已经挂上swap的附属下）。曾经试着开spot instance去执行，但问题没有解决。

连官方都在下载的选项中正式提供Docker的安装方式，Jenkins 2.0这次的表现让我又对它抱持一线希望。

2. React Native串接Cocoapods并通过fastlane部署时的陷阱

在茫茫Google中寻觅觅是否有人写好Flurry或Google Analytics的包装器一阵子之后，我放弃了。因为不是写完之后就摆在那里根本没去更新iOS库，不然就是一抓下来挂上上喷奇怪的错误（Google Analytics的wrapper在虚拟器中测试会喷出奇怪的错误）。绝望之下，我只好卷起袖子自己取代React Native与iOS库了。

官方文件写得很详细，而且我从Exporting Swift（我很惭愧地表示我不会Objective-C）开始做，步骤少得有点过分。颤抖地点击编译并执行，还真的可以跑（数据有确实地传回Google Analytics，真心不骗）。

我的代码有效，但我不知道为什么。

扯远了。这一次真正要分享的是如果React Native有挂Cocoapods，Fastfile要一并更新，否则会发生找不到库的错误。例如以下步骤行：

 健身房（方案：“ app”，项目：“ ios / app.xcodeproj”） 

一开始开发React Native与设定fastlane时，它不会预设你未来会挂Cocoapods上去，因为不是每个人都会用到Cocoapods，或可能使用了Cocoapods以外的套件管理工具。但如果第一次执行完pod安装，Cocoapods实际上会提醒你之后记得都要使用* .xcworkspace考虑到开发时的专案档：

  [！]从现在开始使用`app.xcworkspace`。 

我记得这件事，之后也都是使用* .xcworkspace开发，但每次通过fastlane部署的时候都会在健身房那一步出错，跟我继续说ld找不到库连接。 明明开发时在虚拟机上面跑都没有问题，为什么部署的时候就会出错？

这两个唯一的差异不就是一个透过Xcode执行，一个透过fastlane执行吗？

于是我打开Fastfile，将那行该死的Gym改成以下形式：

 健身房（方案：“ app”，工作区：“ ios / app.xcworkspace”） 

然后什么都不必改，因为Cocoapods在建立工作区时已经把设定都写进去了 。部署成功。

于是，ld找到它的归属，与iOS库从此过着幸福快乐的日子。

必须承认React Native库还是这么少是非战之罪，因为自己动手扭转真是太容易了，而且有很多库是依附在平台之上，要跨平台没有这么容易，根本没人没有动力去为React Native写的图书馆。

3.反应原生动画效果不要滥用

从iOS 7开始支持一种新的手势，如果你从萤幕边缘向右滑动，就可以回到上一个画面。

React Native支持以下过场动画效果，透过实作Navigator的configureScene来控制，目前支持以下几种：

• Navigator.SceneConfigs.PushFromRight（默认）
• Navigator.SceneConfigs.FloatFromRight
• Navigator.SceneConfigs.FloatFromLeft
• Navigator.SceneConfigs.FloatFromBottom
• Navigator.SceneConfigs.FloatFromBottomAndroid
• Navigator.SceneConfigs.FadeAndroid
• Navigator.SceneConfigs.Horizo​​ntalSwipeJump
• Navigator.SceneConfigs.Horizo​​ntalSwipeJumpFromRight
• Navigator.SceneConfigs.VerticalUpSwipeJump
• Navigator.SceneConfigs.VerticalDownSwipeJump

其中最后一个名称中包含“ Swipe”字样的尺寸效果使用上需特别谨慎，尤其是当你的画面中有carousel的元件时，使用者的左右滑动会被bubble up到最上层的View，然后被识别为iOS的滑动返回手势，这对使用者来说是预期之外的行为，应该避免。

视图的上避免刷卡类的过场特效，改以Float或预定的Push取代。另外还有一个潜在的解决方法是覆写carousel的onTouchStart避免事件被冒泡，但由于还没有认真研究过React Native的事件处理机制，所以就先不尝试了。

ocowchun

1. AWS Lambda环境变数设置使用dynamodb

目前开发AWS Lambda时，会使用apex来协助开发，在访问数据库库或调用​​其他API时，就会有相关参数需要设置的问题，由于AWS Lambda本身并没有支持环境变数，所以apex官方有提供自己的实作的方式，实际的做法是产生一个env.json然后打包到功能的zip里面，不过这会派暗示需要将环境变数存储到版本控制的问题，AWS官方的说明文件提到了每个功能有一个对应的IAM角色采用了触发功能，因此在触发funciotn的时候，你的aws-sdk指向的角色就是那个IAM角色，所以我们可以通过IAM角色权限的设置，让该IAM角色拥有重新定义的权限dynamodb的权限，然后将执行功能需要的参数/ config都存储在dynamodb里面，这样就可以功能访问参数/ config的问题，我个人觉得这样的做法也比较符合Twelve-Factor App里面提到有关于config的部分，我们应该要避免将config 存到版本控制系统，同时配置应该要是容易更换的，将配置储存在dynamodb的方式可以帮助我们达成这个目标。

2.做任何烦躁的事情前，试着保持好心情去做，会比苦着一张脸来得好。

这是最近工作与生活上的新体悟。

彼得

识别系统与设计系统：

以前在大学（还在广告系）的时候经常念到许多有关识别系统的案例，企业识别系统（又称CIS）与一个企业，噢不，更正确来说是与一个品牌有非常大的关系。

毕业之后在网路上看到很多识别系统的展现，识别系统实际上包含BI（行为身份），VI（视觉身份），MI（心理身份），而VI（视觉识别）是大家最常见的，很多设计像是这个专案，将品牌的视觉延伸至任何可视的地方。

然而现在网页成为每个企业形象呈现的管道，甚至有些企业的产品是网路服务为主，网页会成为视觉识别的延伸，但网路服务为产品的企业会因产品功能累加，网页会不对更新变动，这时候识别系统就会变得更加重要。

当视觉延伸至网页上时，先前规范品牌在平面输出品上的尺寸，用法就不是非常适用。因为网页具有互动性，并会传递装置萤幕而改变大小与版面，这时候有网路上有强者也提出设计系统的思维。

笔者更专注由过去平面上的规范跨越至网页上的视觉应用与规范，他认为企业都应该要有这种设计系统，而我认为这就是过去视觉识别的取代换与进化，从过去规范平面输出品，实体物件上，跨越到虚拟的介面，如何在介面展现企业品牌的核心概念，呈现品牌个性是未来设计系统（或视觉识别）的重要指标。