idea's blog

根据移动端开发的短短历史来看, 很多移动端开发者在内部比较缺少分工. 相对比, 对于某些上规模的系统, 即使后端工程师这样的一个细分领域的角色, 也会进行分工上的再细分, 例如一般会分成基础服务开发工程师, 业务逻辑开发工程师.

随着移动端应用的复杂度不断增长, 移动端开发工程师这个角色还需要再进行更细的分工. 我们可以参考一些游戏开发行业的分工方式. 我根据自己的理解, 做一下分工.

对于移动端工程师岗位的划分, 我觉得可以分为: 1, 界面工程师; 2, 逻辑工程师.

下面, 根据工作职责和内容划分, 然后结合岗位划分来介绍.

职责1: 界面实现

界面实现这项工作属于界面工程师的职责. 具体来说, 此项工作包括:

1. 使用代码来编写静态的界面UI, 这部分是UI设计图的直接实现, 除去自定义控件部分.
2. 编写自定义控件, 如动画效果控件. 自定义控件可以是通用的, 和业务无关的, 也可以是业务相关的.

职责2: 界面交互

界面实现这项工作也属于界面工程师的职责. 此项工作内容为:

1. 处理界面交互, 如动画效果, 页面内 Tab 切换, 控件的出现和隐藏等.
2. 处理页面之间的跳转.
3. 在界面交互和页面跳转的过程中, 向数据逻辑模块请求数据.
4. 在数据逻辑模块返回数据后, 对界面进行改变, 如组装数据, 启用动效等.

职责3: 数据逻辑

数据逻辑模块是业务逻辑在终端的一种体现, 属于逻辑工程师的工作职责. 逻辑工程师根据业务特点, 从服务器请求数据和将数据保存到服务器(网络交互), 或者从本地请求数据和将数据保存到本地(客户端缓存).

数据逻辑模块一方面和服务端接口进行交互, 另一方面处理用户手机的数据存取(本地存储, 可统称为客户端缓存).

关于内嵌 WebView 控件的代码逻辑

内嵌 WebView 这种技术方案有一些特殊, 因为它既由网页本身实现了界面, 又实现了数据逻辑中的网络交互部分. 如果采用内嵌 WebView 控件的方案, 那么界面程序员的工作就变成:

1. 处理网页跳转与原生(宿主)页面之间的跳转关系
2. 向网页暴露数据逻辑接口

关于页面跳转的实现, 有两种方式:

1. 原生向网页暴露 js 接口, 由网页自主控制页面间的跳转
2. 原生拦截 WebView 的 URL, 改变页面跳转流程

传统的 iOS 应用由于苹果自身的技术所限, 无法实现丰富的 UI 换皮肤(主题)功能, 更不用说 UI 热更新. 如果要实现换皮肤功能, 只能在开发阶段, 提前考虑和设计好几套 UI(xib), 然后在 app 运行时进行切换. 对于想在节日或者某些特殊节点临时给界面加一些点缀, 苹果自身的技术就无法实现了, 只能由开发者自己开动脑筋. 但无论如何, 都需要开发者"提前"想好所有的可能性! 这基本不现实.

而基于 CocoaUI 框架的 iOS 应用, 由于使用 XML+CSS 语言来定义界面, 所以只要程序员在代码中发起一个简单的 HTTP 请求, 就能从服务器端获取一套新的 UI, 从而实现 UI 热更新. 当然, 这要求在业务逻辑功能不变的前提下, 因为 CocoaUI 框架只解决 UI 相关的问题, 而业务逻辑仍然使用 Objective-C/Swift 语言来编写.

对于使用 CocoaUI 框架的应用来说, 要实现换皮肤(UI 热更新), 思路是这样的:

1. 开发阶段, 将一套完整的 XML+CSS 以及图片文件引入项目中, 打包时将包含这些 UI 资源文件, 所以应用在启动和使用过程中, 性能不会有任何影响.

2. 程序中实现文件更新功能, 在运行阶段从服务器端下载新的一套或者几套 XML+CSS+图片 UI 资源文件, 可以采用一些成熟的现有技术, 如断点续传, patch 更新等.

3. 一旦一套完整的 UI 资源文件下载完毕, 就可以根据服务器端的指令, 在某个时间, 或者根据某个条件触发, 切换到新的界面上来.

当然, 你可以用你自己喜欢的加密技术, 用来保护你的 UI 资源, 对于 CocoaUI 来说, 它关心的只是 XML+CSS, 而不一定是文件.

CocoaUI 是一个开源的强大的 iOS 原生 UI 框架, 并不是一个使用 WebView 的混合型浏览器框架. 官方网站是: http://www.cocoaui.com/

W3C 规范中对 CSS 样式的应用算法有规定, 这个规范中的算法比较复杂, 简单来说, 就是根据 CSS 样式选择器中的不同类型的元素出现的次数来计算优先级, 如果某个节点同时命中多个 CSS 样式规则, 以高优先级的样式为准.

W3C 规范具体可以见这个文档: http://www.w3.org/TR/CSS2/cascade.html, "6.4.3 Calculating a selector's specificity" 一节.

例如下面的两条 CSS 样式规则和 HTML:

<style>
ul li .clz{color: #33f;}
li .clz{color: #f33;}
</style>

<ul>
    <li><span class="clz">Hello World!</span></li>
</ul>

如果按照 W3C 规范来计算优先级, 那么会计算出:

第一条的优先级: a=0, b=0, c=1, d=2
第二条的优先级: a=0, b=0, c=1, d=1

Continue reading »

首先介绍下 CocoaUI 框架. CocoaUI 是我开发的一个 iOS UI 开发框架, 用来解决 iOS 设备上的界面布局和多设备屏幕适配问题. 当初, 在开发懒投资 iOS app 的时候, 我们都没有多少 iOS 开发的经验, 根据我们做 Web 开发多年的经验, 我们认为 iOS 的约束布局方式不符合大多数程序员的思维, 所以有必要借鉴 Web 界面布局(主要是流式布局, HTML+CSS 定义), 来开发 iOS 应用.

所以, CocoaUI 框架应运而生了. CocoaUI 在 2015-06-17 开源了, 源码托管在 GitHub 上面. 并且, 我还弄了一个以 cocoaui.com 为域名的网站, 在上面放 CocoaUI 相关的文档等.

有了 CocoaUI, 懒投资 iOS app 的开发速度非常快速, 我们多个传统的 Web 程序员同时开发, 协作得非常好. 由于完全是代码布局, 没有使用 XIB/StoryBoard 这些高度集成的受限技术, 整个项目模块划分非常清晰, 从来不会遇到代码冲突, 做界面的单元测试也极其方便.

我多次说过苹果的约束布局为什么那么落后, 是一项非常丑陋的技术. 而 CocoaUI 使用 Web 浏览器的布局思路和技术, 具有广大的用户基础, 上手非常简单.

目前, 我知道的使用 iOS CocoaUI 框架开发的大中型 app 有: 懒投资, 爱尚三福. 当然, 还有很多 app 没有主动给我反馈. 但 CocoaUI 已经应用非常广泛了.

低级程序员认为自己与高级程序员的区别, 主要是高级程序员任何功能都能编码实现, 编码速度快, 代码无 bug. 正如一惯的那样, 低级程序员之所以低级, 正是因为他们勉强能看到(或者根本看不到)事物的表象而看不到本质. 所以, 低级程序员总结出的一切东西, 你都可以大胆地忽略.

所以, 我们来听听高级程序认为自己与低级程序员的区别是什么. 高级程序员之所以高级, 在于他们认识到代码 bug 是不可避免的, 有千万种理由可以导致 bug, 但他们可以在设计和逻辑上保证(追求)滴水不漏, 并用逻辑的百分之百准确性来减少代码 bug. 没错, 严谨的逻辑能力是高级程序员区别于低级程序员的最主要原因.

可以举一个简单常见例子: 网络购票终端的开发. 当然, 比低级程序员还低级的程序员做不出来. 我们先看看低级程序员是怎么做:
Continue reading »

业务场景：

* server A 经常需要使用rsync将文件同步至 server B
* rsyncd 的配置稍显复杂，不想在 server B 上配置rsyncd
* 出于安全性的考虑，不能完全开放 server A 至 server B 的ssh权限

解决方案：

配置server B上的~/.ssh/authorized_keys， 允许server A使用ssh连接至server B， 但是限制只能使用rsync命令，并且限制rsync上传的目录

在server A上创建用于专门用于rsync验证的ssh密钥

ssh-keygen -C rsync_key -f ./rsync_key -P '' -N ''
#or
ssh-keygen -t rsa

在server B下载 rrsync 存放至 $HOME/bin/rrsync

在server B的~/.ssh/authorized_keys中加入以下内容，行尾的部分即是第一步生成的rsync_key.pub的内容：

command="$HOME/bin/rrsync /data/work/package/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAA**content of rsync_key** rsync_key

在server A上可以通过下面的rsync命令把local_name上传至server B的/data/work/package/remote_name来传输文件：

rsync -av -e 'ssh -o StrictHostKeyChecking=no -i /path/to/rsync_key' local_name user@serverB:remote_name

参考链接：Restricting SSH Access to rsync

转自: http://oylb.in/blog/2015/09/01/restrict-rsync-with-authorized-keys/
原标题: 使用authorized_keys限制rsync