Linuxeden Open Source Community: 十月 2017

2017年10月31日星期二

开源美图 2017 11 01

Linuxeden 开源社区 --

The post 开源美图 2017 11 01 appeared first on Linuxeden开源社区.

http://ift.tt/2z1twPD

一次前后端分离的实践

Linuxeden 开源社区 --

作者蔡佳成

前后端分离该如何做? 这个问题，不同的技术人员，由于所处的岗位不一样，给出的答案都不一样。

前后端分离的问题，不仅仅是技术上的选型问题，还涉及到整个团队在认知、职责、流程上面重新定义的问题，这也是为什么前后端分离概念看起来简单易懂，但真正团队在落地的时候，一不小心，往往鸡飞狗跳，甚至最终放弃” 治疗”。

下面，基于自己之前的对一个团队前后端分离改造的实践经历，介绍一下如何打造一个前后端分离的技术团队。

背景介绍

项目介绍

交付一个服务于跨境电商的供应链金融项目。需求已经相对明确，产品的原型已经出来，大概有 60 多个 Web 端的企业内部信息化的页面，以平均 1 个页面 2。5 个接口来计算，整个工程差不多有 150 个接口。

项目的交付需求还包括技术使用前后端分离和微服务架构。

项目交付的时间需求一共是一个半月，大概 7 周的时间。

团队介绍

项目团队一共 8 个后端开发，4 个前端，2 个 QA，2 个产品，团队是从其它团队中，各自抽调出来的，之前都没有配合过。

团队的技术栈是传统的 SpringMVC + JSP + JQuery，团队成员对前后端分离的概念都只是听说，并没有任何实操的经历。

项目启动

古语云: 兵马未动，粮草先行。

1. 统一认识

任何技术团队都是有惯性的，新的变化 (包括新技术，新的业务，新的开发模式等) 在团队中的’ 落地生根’ 一般都有一个缓慢的适应过程。

而碰到这种时间紧、任务重的项目，不仅短期内需要引入这么多新的知识，并且还要求快速出成果，团队成员里，眼里都是各种各样的困难，从而影响到技术人员的心理状态，产生各种消极的，甚至排斥的想法。

所以，项目启动的时候，如何统一认识，快速让整个团队进入工作状态，是最重要的问题。

2. 划分边界，确定流程

从本质上来说，前后端分离，相对于前后端混合团队的最大差别就在于，团队内部的分工颗粒度更细。或者也可以称为更加地解耦，从而让各个小团队在工作中更加地专注并且高效

然后，解决分工的问题，相应也要引出协作的问题。把分工颗粒度切细了，边界划分清楚了，相应地也需要定义清楚各个小团队如何去高效协作，这样才能保证即高效，也不会相互干扰。

所以，前后端分离的第一步，也是最关键的一步，就是梳理清楚开发流程，及相应的角色职责。

角色职责

前端团队 负责页面展现的接口设计，功能页面的开发。并最终提交给 QA 做功能测试
后端团队 负责后端的功能模块实现，根据前端定义的接口实现对外接口；
测试团队 负责衔接前端和后端团队

开发流程

(点击放大图像)

如上图所示，里面定义出了三个团队在前后端分离的流程中，各自的工作内容。其中最需要关注的就在于中间各个团队相互衔接的流程。

提交接口测试 后端团队 -> 测试团队。后端团队按功能模块开发完接口，提交给测试团队进行集成接口测试
后端接口对接 测试团队 -> 前端团队。测试团队验收完接口后，可以移交给前端团队进行页面级别的接口接入。
提交功能测试 前端团队 -> 测试团队。前端团队完成了产品的包括页面及接口上对接的工作后，就可以提交给测试团队进行最终的功能页面验收了。

过程性文档

开发流程中，每一个核心的环节，特别是涉及到多方分工协作的环节，都需要有指定的文档输出及相应的评审。

前后端分离中，其中比较重要的过程性文档有如下四个：

接口契约文档 用于定义前端与后端之间的接口定义
- 责任方 : 前端团队第一个版本的接口契约定义，一定是前端团队出的。是的，你没有看错，后端团队并不适合出接口的定义，因为前端团队的思维方式是 基于页面交互 来考虑的，后端团队的思维方式是 基于结构化实体 来考虑的。
- 评审方 ：后端团队，测试 QA，产品经理
集成测试用例文档 用于定义验收接口的用例
- 责任方 : 测试 QA 团队
- 评审方 : 后端团队，产品经理
功能测试用例文档 用于定义验收页面功能的用例
- 评审方 : 前端团队，产品经理
- 责任方 : 测试 QA 团队
单元测试用例文档 用于定义后端各个功能模块的单元用例
- 评审方 : 后端团队，产品经理
- 责任方 : 后端团队

3. 技术框架

前后端分离，技术团队的框架选型也是需要重点考虑的，一般这个职责都是各端开发的技术负责人来组织调研，并确定最终的框架。

技术框架的选型方式

编程语言 不同团队的编程语言基础技术栈都不一样，比如有些团队熟悉 PHP，有些团队甚至基于 GO 等，更多的核心考量点还是在于，团队成员接受度高，编程语言生态活跃度这几个维度。
框架选型 编程语言之上的各种框架选型，如网络框架，数据库框架等，更多的还是基于技术负责人的架构经验来进行选型。只要记住一个原则： 没有通用的框架，只有合适的框架

我们团队最终的框架选型：

前端框架

编程语言： ECMAScript + React React，Angular，Vue 都是优秀的前端框架，选择上更偏向于 Github 上面的生态中，React 是最活跃，关注度最大的层面上来考量的。
开发框架： DVA + Ant-design 阿里开源的基于 React 的框架的封装，其中有一个示例性的 demo 工程 antd-admin，可以在团队刚起步的时候，快速进入开发流程

后端框架

编程语言：Java 8 后端开发是 Java 团队，不过建议使用 Java8 之前先做 Java 8 的培训，特别是 Lambda，Optinal 相关使用方法，应用场景相关的新特性培训。
开发框架：SpringBoot 一个好像不需要过多解释的框架。

集成测试框架

如果团队中的测试 QA 尚不俱备技术开发能力，建议使用 Postman 来进行集成接口测试

编程语言：Python 测试开发最方便的编程语言
开发框架：Pytest 测试用例框架

项目管理

到这里，准备工作基本就结束了。下面，你需要对整个项目的流程进行规定。

1. 定义 0.1 的里程碑

所有技术框架都只是调研的，所有流程都只是浮于表面的。

项目开工的第一个核心任务就是讨论出最小的工程子集，目标是可以跑通所有的流程及相应的技术框架。

整个团队形成一个共识，然后启动开发。从 0 到 0.1 的过程中，会碰到大量的问题，这些问题只要不阻塞开发流程的推进，即使处理得磕磕碰碰的，都可以暂时放一边。比如说文档的格式如何写，代码的风格之类的。

当 0.1 的里程碑完成后，整个团队会对前后端分离，不管是流程上，还是技术上，都会有一个基本的认识，并且，会有一定的成就感。这也代表前后端分离已经有了一个好的开端了。

2. 前后端进度分离

当团队熟悉前后端分离的流程后，前端团队和后端团队的进度就可以考虑彻底分开了。

前端团队的进度

可以基于 Mock 接口的方式，分成三个阶段：

按页面划分，快速出所有的页面只考虑量，不考虑质，以基本跑通所有的 Mock 接口为标准。这里更多的考虑在于，前端接触新的框架，会积累很多问题，包括 CSS 之类的，包括接口调用之类的，这些问题都有共通性，可以在下一次迭代的时候，总结出问题，分不同的人去解决。
基于所有的页面进行迭代划分不同的人去解决团队积累下来的问题，并统一修复。可以尝试抽出一些共性的组件
分批接入后端的模块接口到这个阶段的时候，后端的接口理论上 QA 根据模块，已经验收了一部分了，可以开始分批接入，并最终提交给 QA 进行功能上的测试

后端团队的进度

按模块切分开发，接口分批提交验收。

后端可以基于业务来切分子模块，然后，各个模块并行开发。接口实现后，由 QA 去进行集成用例的验收。

测试团队的工作内容

QA 在前后端分离流程，扮演着足球’ 中场’ 的角色，这个角色把前端团队这个’ 前场’ 和后端团队这个’ 后场’，串联起来，承上启下，让他们可以各司其职，降低相互之间的耦合性。

核心工作就三个部分：

分批次验收后端的模块接口在没有页面的前提下，使用工具，参考集成测试用例，对接口的健壮性，可靠性进行详细验证，保证在前端页面开始接入接口的时候，接口是稳定可靠的。
分批次验收前端的功能页面基于功能测试用例，进行页面级别上的功能回归
整合前后端的 BUG 信息前后端的 BUG 信息全部是反馈给 QA，由 QA 统一去追相应的技术人员。比如说前端发现有个接口有问题，只反馈给 QA，剩下的工作就是由 QA 去找相应的后端负责人。

从 1 到 N 的迭代

在这个过程中，团队需要的是耐心及专注。

团队的技术成长都是有节奏的，是没有办法一步到位的。

做为项目或者技术负责人，在这个时候，要有相对宽容的心态是看待这个问题。

随着项目一次次迭代，会引出一个个问题，比如说，如何更加有效地写单元测试用例，如何更加有效的提高页面的渲染效率，如何让页面的组件更加的通用化。

请注意” 更加” 这个词，团队在不断解决” 更加” 的问题过程中，也是不断成长的过程。

最终，整个技术团队会演化成一个高效分工，专注各自领域的前后端分离的快速开发的团队。

转自 http://ift.tt/2ijRVWd

The post 一次前后端分离的实践 appeared first on Linuxeden开源社区.

http://ift.tt/2gRT6vB

2017 机器学习调查报告：Python 最火，R 极具潜力

Linuxeden 开源社区 -- Python

数据平台 Kaggle 近日发布了 2017 机器学习及数据科学调查报告，这也是 Kaggle 首次进行全行业调查。调查共收到超过 16000 份回复，受访内容包括最受欢迎的编程语言、不同国家数据科学家的平均年龄、不同国家的平均年薪等。

点此查阅完整报告

下面主要看看工具使用方面的结果。请注意，该报告包含多个国家的数据，可能存在收集不够全面的情况，仅供参考。

年龄

从全球范围来看，本次调查对象的平均年龄在 30 岁左右。当然，各个国家的数值会有差异，中国的机器学习从业者年龄的中位数是 25 岁。

全球全职工作者为 65.7% ，其中中国为 53.% ，美国占比较高，达 70.9% 。

Logistic 回归是除了军事和国安领域外，最常用的数据科学研究方法。在军事和国防安全领域，神经网络被使用更多。

在工具语言使用方面，Python 是数据科学家使用最多的语言。同时，统计学家对 R 语言的忠诚度很高。

关系型数据是最常用的数据类型，学术研究者和国防安全领域则更亲睐文本和图像。

Git 是他们最常用的代码共享和托管方式。

Dirty Data（脏数据）是从业者遇到的最大障碍。此外，理解不同算法的能力不够也是困扰数据工作者的一大障碍。缺乏有效管理和资金支持，是面临的两大外在困境。

有趣的是，只使用 Python 或只使用 R 的都觉得他们做出了正确的选择。但是，如果你去询问那些既使用 Python 也使用 R 的人，推荐使用 Python 的可能会是 R 的两倍。

数据科学是个变化极快的领域，业内人员需要不断更新知识体系，才可以在业内保持一定地位，不被时代淘汰。Stack Overflow Q&A、Conferences 和 Podcasts 是已从业者经常使用的学习平台。

更多内容可点此查阅完整报告。

转自 http://ift.tt/2gPz0Ci

The post 2017 机器学习调查报告：Python 最火，R 极具潜力 appeared first on Linuxeden开源社区.

http://ift.tt/2ijRoUd

Wine 2.20 发布。Wine（“Wine Is Not an Emulator” 的首字母缩写）是一个能够在多种 POSIX-compliant 操作系统（诸如 Linux，macOS 及 BSD 等）上运行 Windows 应用的兼容层。Wine 不是像虚拟机或者模拟器一样模仿内部的 Windows 逻辑，而是将 Windows API 调用翻译成为动态的 POSIX 调用，免除了性能和其他一些行为的内存占用，让你能够干净地集合 Windows 应用到你的桌面。

主页更新内容：

Improved event support in MSHTML.
Preloader support on ARM64.
Interpolation modes in Direct3D.
Improved metafile support in GdiPlus.
Initial version of Kerberos5 Authentication Package.
OLE clipboard cache improvements.
Various bug fixes.

下载地址：http://ift.tt/2A4ztJg

昨天召开的 WineConf2017 大会上，Wine 项目负责人 Alexandre Julliard 表示 Wine 3.0 有望年底发布。

Wine 3.0 将切换至 Windows 7 作为默认 Windows 版本，并会部署 Direct3D 命令和信息模式的管道。不过在 Wine 3.0 正式发布之前，还需要修复大约 160 处 BUG。

大会上表示，Wine 3.0 会赶在今年年底之前发布，但不会支持下一代 Vulkan 图形 API，或 Wayland 显示服务器，这些重磅功能将会在明年添加到 Wine 中。

转自 http://ift.tt/2xIQiIb

The post Wine 2.20 版发布，3.0 版将在年底更新 appeared first on Linuxeden开源社区.

http://ift.tt/2A2vZqF

AMP 网页秒开技术开源 2 周年，Google 公布成果

Linuxeden 开源社区 --

在网络中，速度和用户体验极为重要，如果网页加载时间超过 3 秒，53% 的移动网站访问就会被放弃。为改变这种状况，Google 在两年前联合 8 家科技公司以及近 30 家新闻机构一起发布了一个名为移动页面加速（Accelerated Mobile Pages）的开源项目，旨在让网页真正实现秒开。

Google 搜索副总裁、Google AMP 项目负责人 David Besbris 近日公布了其最新成果，他表示 AMP 的合作伙伴已超过 2500 万个网站域名，已发布超过 40 亿个 AMP 网页。不仅 AMP 网页数量增多了，其加载速度也提高了，一个 AMP 网页从 Google 搜索加载的时间中间值不到半秒。

David Besbris 还对所有贡献者表示感谢：“ AMP 的成功完全依赖于项目的贡献者，目前已有 400 多人直接编写代码，另有 10500 人参与项目，在此对每个人的贡献表示诚挚的感谢。还有一些企业在支持 AMP 的过程中扮演着越来越积极的角色。比如，Automattic 过去几个月来一直配合我们改进 WordPress 插件的质量。不仅 WordPress.com 社区积极使用，其 VIP 客户（如 The New York Post 和 PMC）在实现后也取得了卓越的成效。”

转自 http://ift.tt/2A4Yt2K