AI丨看大神是如何总结2018和预测2019的

在之前的推送中,我们看到了很多专家对AI、数据科学与分析的2018年总结以及2019年趋势预测,今天我们再来看看2018年AI、机器学习的技术概述及2019年发展趋势,本文是TalkingData University翻译自Medium上的一篇文章,原文作者Pranav Dar,点击【阅读原文】可查看英文原文。

注:由于文章过长,将分为上下两次进行推送,上半部分主要的内容为:自然语言处理(NLP)、计算机视觉的相关内容。

导论

过去几年对AI爱好者和机器学习从业者来说像梦一样。 这些技术已经从利基发展成为了主流,并且今天正在影响着数百万人的生活。各国现在都有专门的AI部门和预算,确保自己一直与处于这场比赛之中。

对数据科学专业人员来说也是如此。 几年前,你会很自然地知道一些新的工具和技术。 但现在不是了! 在这个领域发生了很多事情,有太多都需要加快脚步跟上,甚至有时令人难以置信。

这就是为什么我想从数据科学从业者的角度,退一步看AI一些关键领域的发展。这些突破是什么? 2018年发生了什么,2019年会发生什么?

P.S. 与任何预测一样,这些都是我的结论。这些是我试图连接起来的点。 如果您有不同的观点 ,可以在本文下的留言区域畅所欲言。

我们将在本文中覆盖的领域:

  • 自然语言处理(NLP)
  • 计算机视觉
  • 工具和库
  • 强化学习
  • 更好的AI – 伦理AI

自然语言处理(NLP)

让机器解析单词和句子似乎是在做梦。语言在方方面面有太多的细微差别,甚至人类有时都难以掌握,但2018年确实是NLP的分水岭。

我们看到了一个又一个显著的突破–

ULMFiT,ELMo,OpenAI的Transformer和Google的BERT等等。迁移学习(能够将预训练模型应用于数据的艺术)成功应用于NLP任务,为无限的潜在应用打开了大门。近几次我们与Sebastian Ruder的播客进一步巩固了我们对他的领域继续走下去的信念。(提醒一下,这是所有NLP爱好者必读的播客)。

ULMFiT

ULMFiT是由Sebastian Ruder和fast.ai的Jeremy Howard设计、今年第一个启动NLP迁移学习的框架。对于没有经验的人来说,它代表通用语言模型微调。 Jeremy和Sebastian真的在ULMFiT中做到了“通用”这个词—该框架几乎可以应用于任何NLP任务!

谈到ULMFiT中最棒的部分以及我们即将看到什么样的后续框架?你不需要从头开始训练模型!这些研究人员为您完成了困难的部分,您可以学习并将其应用到您自己的项目中。ULMFiT是六个文本分类任务中表现最优的。

您可以阅读Prateek Joshi所作的优秀教程,关于如何开始使用ULMFiT解决任何文本分类问题。

ELMo

想猜猜ELMo代表什么?它是语言模型嵌入的简称。很有创意吧?除了名字与著名的芝麻街角色相似,ELMo一发布就引起了机器学习社区的注意。

ELMo使用语言模型来获取每个单词的嵌入,同时还会考虑单词适用的句子或段落上下文。语境是NLP一个非常重要的方面,但大多数人以前都没有掌握。ELMo使用双向LSTM来创建嵌入。如果这听起来很拗口也不用担心 – 请查看这篇文章(原文有链接),以便非常简单地了解LSTM是什么以及它们是如何工作的。

与ULMFiT一样,ELMo显著提高了众多NLP任务的性能,如情感分析和问答。

Google’s BERT

相当多的专家声称BERT的发布标志着NLP的新时代。继ULMFiT和ELMo之后,BERT凭借其性能真正击败了竞争对手。正如原论文所述,“BERT在概念上简单,同时有具备强大的经验”。

BERT在11个(是的,11个!)NLP任务中获得了最优结果。 来看一下在SQuAD基准测试中他们的结果:

SQuAD v1.1排行榜(2018年10月8日)Test EMTest F11st Place

Ensemble – BERT87.493.22nd Place Ensemble – nlnet86.091.71st Place Single Model – BERT85.191.82nd Place Single Model – nlnet83.590.1

有兴趣入门吗? 您可以使用PyTorch实现,或使用Google自己的TensorFlow代码尝试在您自己的计算机上复现。

我很确定你想知道BERT在这一点上代表什么。它是Transformer的双向编码器表示。

Facebook的PyText

Facebook怎么可能退出竞争呢?他们开源了他们自己的深度学习NLP框架PyText。 它于12月23日这一周发布,所以我还在试用它,但从目前早期的评论看是非常有希望的。根据Facebook发表的研究,PyText使会话模型的准确性提高了10%,并缩短了训练时间。

PyText实际上落后于Facebook其他一些产品,如FBMessenger。 因此,研究它来为您自己的投资增加一些现实世界的价值(除了您将获得的宝贵知识)。

您可以通过从此GitHub下载代码来自行尝试(原文有链接)。

Google Duplex

如果你还没有听说过Google Duplex,你都干嘛去了?!Sundar Pichai用一个demo十分精彩的展示了它,从那以后它一直是头条新闻:

由于这是Google的产品,因此他们很有可能开源背后的代码。它是展出时可用的一个相当棒的音频处理应用程序。当然,它引发了许多道德和隐私问题,但这是本文后面要讨论的。就目前而言,我们只要陶醉于近年来我们与机器学习的关系就可以了。

2019年NLP的趋势

谁还能比Sebastian Ruder本人提出NLP 2019年更好的发展方向?以下是他的想法:

  • 预训练的语言模型嵌入将无处不在,最先进的模型不使用它们是几乎不可能的
  • 我们将看到可以编码专门信息的预训练,这些信息是对语言模型嵌入的补充。我们将能够根据任务的要求组合不同类型的预训练
  • 我们将看到多语言应用程序和跨语言模型上的更多工作。特别是在跨语言词嵌入的基础上,我们将看到深度预训练跨语言表示的出现。

计算机视觉

这是现在深度学习中最受欢迎的领域。我觉得我们已经在很大程度上获得了计算机视觉低处的果实,并且已经在某种程度上到达了精炼阶段。无论是图像还是视频,我们都看到了大量的框架和库,这使得计算机视觉任务变得轻而易举。

我们今年在Analytics Vidhya花了很多时间研究这些概念的平民化。可以看看我们的计算机视觉特定文章(原文有链接),涵盖从视频与图像中的对象检测到预训练模型列表等主题,帮助您开始深度学习之旅。

如果您对这个美妙的领域感到好奇(实际上它很快将成为业内最热门的工作之一),那么请继续学习我们的“使用深度学习的计算机视觉”课程开始您的旅程。

BigGANs 的发布

Ian Goodfellow在2014年设计了GANs,这个概念催生了多种多样的应用程序。年复一年,我们看到原始概念正在调整以适应实际用例。但直到今年,有一件事情仍然相当一致:机器生成的图像相当容易被认出。在框架中总会存在一些不一致,这使得区别非常明显。

但最近几个月,这个区别已开始模糊。随着BigGANs的创建,这种区别可以永久消除。以下是使用此方法生成的图像:

除非你拿显微镜看,否则你将无法判断这些图是否有问题。担心还是兴奋?我会把这个问题留给你,但毫无疑问GANs正在改变我们对数字图像(和视频)的感知方式。

对于这方面的数据科学家来说,这些模型首先在ImageNet数据集上进行训练,接下来JFT-300M数据集可以展示模型的良好迁移。我还要引导您进入GANs页面 – 一种可视化和理解GAN的非常酷的方式。

Fast.ai的模型在ImageNet上训练仅用18分钟

这是一个非常酷的进展。人们普遍认为,需要大量数据以及很重的计算资源才能执行合适的深度学习任务。这包括在ImageNet数据集上从头开始训练模型。我理解这种看法—我们大多数人都认为如此,直到Fast.ai的出现证明我们都错了。

他们的模型在令人惊讶的18分钟时间内,得到了93%的准确率。他们在博客中详细介绍了使用的硬件–16个公有AWS云实例,每个实例都有8个NVIDIA V100 GPU。他们使用fastai和PyTorch库构建了算法。

所有加在一起的总成本仅为40美元!Jeremy在这里更详细地描述了他们的方法,包括技术。

NVIDIA的vid2vid技术

在过去的4-5年里,图像处理已经实现了跨越式发展,但视频呢?事实证明,从静态框架转换为动态框架的方法比大多数人想象的要困难一些。 你能拍摄视频序列并预测下一帧会发生什么吗?这些问题之前已被探索过,但已发表的研究充其量还是模糊不清。

NVIDIA在今年早些时候决定开源他们的方法,并得到了广泛的赞誉。他们vid2vid方法的目标是从给定的输入视频学习映射函数,以产生输出视频,这个输出视频以令人难以置信的精度描绘了输入视频的内容。

您可以在GitHub上找到他们的PyTorch实现。

2019年计算机视觉趋势预测

就像我之前提到的那样,我们可能会在2019年看到改动而不是创新。尤其在这些领域–自动驾驶汽车,面部识别算法,虚拟现实等。欢迎提出不同意见—我很想知道明年会诞生什么目前还没有的东西。

无人机目前还在等待政府和政策的批准,最终可能在美国获得批准(印度要远远落后)。就个人而言,我希望看到很多研究在实际场景中实施。像CVPR和ICML这样的会议描绘了这个领域的最新成果,但这些项目有多接近现实中的使用呢?

视觉问答和视觉对话系统可能很快迎来期待已久的首次亮相。这些系统缺乏概括的能力,但我们期望可以很快看到一种综合的多模式方法。

自我监督学习今年来到了一线。我可以打赌明年它将用于更多的研究。这是一个非常酷的学习线–标签直接由我们输入的数据确定,而不是浪费时间手动标记图像。

解惑丨如何在边缘设备上适配大型神经网络?

原文作者:Bharath Raj

译者:TalkingData 赵磊

原文地址:http://t.cn/Rkofy1e

对于任何想要创建可扩展服务的人来说,部署有内存限制的深度学习算法都是一种挑战。从长远来看,相比昂贵的云服务,在边缘设备上离线部署模型更为便宜,而且还有其他好处。唯一的缺点是它们缺乏内存和计算能力。

本文探索了一些可以用来在内存受限的设备中适配神经网络的技术。因为“训练”和“推理”阶段用到了不同的技术,所以将把它们分开来讨论。

训练

某些应用程序需要在线学习。也就是说,模型要根据反馈或额外的数据进行改进。在边缘设备部署这样的应用程序会给您的模型带来一个切实的资源约束。这里有4种方法可以减少此类模型的内存消耗。

梯度检查点像 TensorFlow 这样的框架需要消耗大量的内存用于训练。在前向传播过程中,计算图中的每个节点的值都会被计算并保存在内存中,因为在反向传播时计算梯度时需要用到。

每个节点的值在前向传播后保存,以便在反向传播中计算梯度。源码:

https://github.com/openai/gradient-checkpointing

通常情况下,这是可以做到的,但当模型变得越来越复杂时,内存消耗会急剧增加。一个巧妙的回避解决方案是在需要时重新计算节点的值,而不是将它们保存到内存中。

重新计算节点值用以计算梯度。注意,我们需要分别做若干次前向传播来完成一个反向传播。源码:

https://github.com/openai/gradient-checkpointing

然而,如上所示,计算成本将显著增加。解决办法是在内存中只保存一些节点,而在需要时重新计算其他节点。这些保存的节点称为“检查点”。这极大地减少了因深层神经网络而积累的内存消耗。如图所示:

左边的第二个节点是检查点节点。它在减少了内存消耗的同时提供了合理的时间成本。源码:

https://github.com/openai/gradient-checkpointing

以速度换内存(重计算)根据上面的想法,可以重新计算某些操作用以节省时间。Memory Efficient DenseNet 实现就是一个很好的例子。

DenseNet 的一个 dense 块

原文:https://arxiv.org/abs/1608.06993

DenseNets 具有很高的参数效率,但内存效率也很低。之所以出现这种矛盾,是因为拼接和批标准化操作造成的。

为了使卷积在 GPU 上更高效,必须连续地设置这些值。因此,在连接之后,cudNN 在 GPU 上连续地排列这些值。这涉及到大量的冗余内存分配。类似地,正如本文所解释的那样,批标准化涉及到过多的内存分配。这两种操作都会造成内存以二次增长。DenseNets 有大量的拼接和批标准化,因此它们的内存效率很低。

将原始的拼接和批标准化操作

与它们的高效内存实现相比较原文:

https://arxiv.org/pdf/1707.06990.pdf

上述问题的一个简洁的解决方案涉及两个关键的观察。

首先,拼接和批标准化操作不是时间密集型的。因此,我们可以在需要的时候重新计算这些值,而不是保存所有冗余内存。其次,我们可以使用“共享内存空间”来转储输出,而不是为输出分配“新”内存空间。

我们可以重写这个共享空间来存储其他拼接操作的输出。也可以在需要的时候重新计算拼接操作来进行梯度计算。同理还可以将它扩展到批标准化操作。这个简单的技巧节省了大量的 GPU 内存,通过增加少量的计算时间来换取。

减少精度在一篇优秀的博客中,Pete Warden 解释了如何用8位浮点值训练神经网络。由于精度的降低,出现了一些问题,其中一部分如下:

如本文所述,“激活值、梯度和参数”有非常不同的范围。一个定点表征并不理想。这篇论文声称,一个“动态的固定点”表征将非常适合于低精度的神经网络。正如 Pete Warden 的另一篇博客所述,较低的精度意味着更大的偏差。通常,如果错误是完全随机的,那么它们很有可能相互抵消。然而,0被广泛用于 padding、dropout 和ReLU,在低精度浮点格式中,0的精确表示也许是不可能的,因此可能会在性能中引入总体偏差。神经网络的架构工程架构工程涉及到设计准确率、内存和速度最优的神经网络结构。有几种方法可以在空间和时间上优化卷积。

将 NxN 的卷积分解成 Nx1 和 1 xN 卷积的组合。这可以节省大量的空间,同时也提高了计算速度。在 Inception 网络的更新版本中使用了这种方案以及其他一些优化技巧。更详细的讨论,请查看这篇博客:https://towardsdatascience.com/a-simple-guide-to-the-versions-of-the-inception-network-7fc52b863202在 MobileNet 和 Xception Net 中使用深度可分离的卷积。关于卷积的类型的详细讨论,请查看这篇博客:https://towardsdatascience.com/types-of-convolutions-in-deep-learning-717013397f4d使用1×1卷积作为一个瓶颈来减少传入通道的数量。这种技术已经在几种流行的神经网络中使用了。

谷歌的 AutoML 的描述,视频:

https://www.youtube.com/watch?reload=9&v=Y2VF8tmLFHw

一个有趣的解决方案是让机器为特定的问题确定最佳的架构。神经架构搜索使用 ML 来为给定的分类问题找到最好的神经网络体系结构。当在 ImageNet 上使用时,它生成的网络(NASNet)是迄今为止创建的最佳性能模型之一。谷歌的 AutoML 也遵循同样的原则。

推理

为边缘设备推理拟合模型相对比较容易。本节将介绍可用于优化边缘设备神经网络的技术。

去除臃肿像 TensorFlow 这样的机器学习框架,消耗了大量的内存空间来创建计算图。这个额外的空间对于加速训练过程是很有用的,但是它不用于推理。因此,专门用于训练的计算图部分可以被删除,我们把这部分称为计算图的“臃肿”。

建议将模型检查点转换为冻结的推理图。这个过程会自动删除消耗内存的“臃肿”部分。当转换为一个冻结的推理图时,从模型检查点抛出“资源耗尽的错误”的计算图有时可以被适配进内存中。

修剪特征在 Scikit-Learn 上的一些机器学习模型(如随机森林和XGBoost)会输出一个名为特征重要度(feature_importance)的属性。这个属性代表了分类或回归任务的每个特性的重要性。我们可以简单地删除那些最不重要的特征。如果您的模型有大量的特征,而且不能通过任何其他方法来减少,这将非常有用。

一个特征重要度可视图的例子:

https://machinelearningmastery.com/feature-importance-and-feature-selection-with-xgboost-in-python/

类似地,在神经网络中,许多权重值接近于零。我们可以简单地删除这些连接。然而,删除层间的单个连接会形成稀疏的矩阵。创建高效推理引擎(硬件)方面的工作正在进行,它可以无缝地处理稀疏操作。然而,大多数 ML 框架都是将稀疏矩阵转换成密集的形式,然后再将它们发送到 GPU 上。

去掉一个无关紧要的过滤器,原文:

http://machinethink.net/blog/compressing-deep-neural-nets/

相反,可以移除无关紧要的神经元,并稍微对模型进行重新训练。对于 CNNs,也可以删除整个过滤器。研究和实验表明,通过使用这种方法,可以保留大部分的精确度,同时获得大规模的缩小。

权重共享为了更好地说明权重的共享,参考一下这篇深度压缩论文:https://arxiv.org/pdf/1510.00149.pdf中给出的例子。一个4×4的权重矩阵。它有16个32位浮点值。我们需要512位(16*32)来表示这个矩阵。

我们将权重值量化到4个级别,但是保留它们的32位性质。现在,4×4的权重矩阵只有4个唯一的值。4个唯一的值存储在一个单独的(共享)内存空间中。我们可以分别给这4个唯一值一个2位地址(可能的地址值为0、1、2和3)。

可以通过使用2位地址来引用权重。因此,这里获得了一个新的4×4矩阵,其中包含2位地址,矩阵中的每个位置都指向共享内存空间中的一个位置。这个方法需要160位(162+432)来表示整个矩阵,得到了3.2的大小减少因子。

不用说,这种规模的缩小伴随着时间复杂度的增加。但是,访问共享内存并不会消耗太多的时间。

量子化和更低的精度(推理)回想一下,在本篇文章的“训练”部分中提到了精度的降低。对于推理来说,精确度的降低并不像训练过程那么麻烦。权重可以被转换成更低的精度格式,并发送到推理过程中。但是,可能需要轻微的权重调整来防止精确度的急剧下降。

编码修剪和量子化的权重可以通过编码进一步优化。Huffman 编码可以用更少的位表示最频繁的权重值。因此,在比特级别上,一个 Huffman 编码的字符串比普通字符串占用更小的空间。

深度压缩探讨了使用无损压缩技术的编码,如 Huffman 。然而,研究也探讨了有损压缩技术的使用。这两种方法的缺点是翻译的开销。

推理优化器到目前为止,我们已经讨论了一些很有建设性的想法,但是若从头开始实现它们需要相当长的时间。这就是推理优化器发挥作用的地方。例如,Nvidia 的 TensorRT 包含了所有以上这些想法。并提供了一个经过训练的神经网络的“优化推理引擎”。

TensorRT:

https://developer.nvidia.com/tensorrt

此外,TensorRT 可以优化模型,使其能够更好地利用 Nvidia 的硬件。下面是一个使用 TensorRT 优化的模型更有效地利用了 Nvidia 的 V100 的例子。

在 Nvidia 的 V100 上使用 TensorRT 优化的模型:

https://devblogs.nvidia.com/tensorrt-3-faster-tensorflow-inference/

知识蒸馏我们可以“教”较小的模型来模拟更健壮、更大的模型,而无需花哨的优化技术。这项技术被称为“知识蒸馏”,它是谷歌“ Learn2Compress ”的重要组成部分。

Teacher-Student 模型:

https://ai.googleblog.com/2018/05/custom-on-device-ml-models.html

通过使用这种方法,我们可以强制使用更小的模型,这些模型可以适配在边缘设备上,以达到大型模型的性能水平。据统计,精确度的下降是最小的。

更多信息可以参考Hinton的论文:

https://arxiv.org/pdf/1503.02531.pdf

技术专栏丨Fabric 和 Sawtooth 技术分析(下)

在前一篇文章(Fabric和Sawtooth技术分析(上))中,我们着重跟大家分享了 Fabric 相关的内容,在本篇文章中,我们将围绕着 Sawtooth 进行一些分析和探讨。

Sawtooth 结构及分析
Sawtooth 是 Intel 公司推出的企业级区块链,2018年 Intel 将其贡献给 Hypherlegder 项目。本文中笔者主要从 Sawtooth 的存储结构、数据结构、网络结构方面做简要介绍。

Sawtooth

Sawtooth 的存储结构

Sawtooth 使用名为 Radix Merkle Tree 的存储结构,它融合了 Radix Tree 和 Merkle Hash Tree 的功能,先看看这两种结构:

  • Radix Tree

Radix Tree 概念比较拗口,简单地说就记住在这个树上,任何一个叶子节点的位置和一个 01 串唯一对应,因此我们可以根据一个 01 串组成的地址确定叶节点是谁。

下图是一个 Sawtooth 所使用的 Radix Tree 对应的字符串,由70个16进制字符组成,前6位称为命名空间前缀(Namespace prefix),后边的是该前缀所对应的空间内可分配的地址范围。

我们以 Sawtooth 预定义的一个 Transaction Family-IntegerKey 为例,注意 Sawtooth中 的 Transaction Family 相当于 Fabric 中的 chaincode 或者 Ethereum 中的 Smart Contract 。IntegerKey 的前缀(prefix)计算法方法是:hashlib.sha512(‘intkey’.encode(‘utf-8’)).hexdigest()[0:6],运算结果是 ‘1cf126’。那么,存储该 transaction family 中一个 block 的地址就是:

address = “1cf126” + hashlib.sha512(‘name’.encode(‘utf-8’)).hexdigest()[-64:]

当然,地址的构成也可以更复杂一些,比如,有个自定义 Transaction Family 的前缀是 prefix = “my-transaction-family-namespace-example”。命名空间可以进一步划分为 object-type 和 unique-object-identifier 。其中,object-type = “widget-type”,unique-object-identifier = ”unique-widget-identifier”。那么,对应的字符串就可以计算如下:

hashlib.sha256(“my-transaction-family-namespace-example”.encode(‘utf-8’)).hexdigest()[:6] + hashlib.sha256(“widget-type”.encode(‘utf-8’)).hexdigest()[:4]

+ hashlib.sha256(“unique-widget-identifier”.encode(‘utf-8’)).hexdigest()[:60]

最后得到下面的地址:

‘4ae1df0ad3ac05fdc7342c50d909d2331e296badb661416896f727131207db276a908e’

众所周知,2的10次方是1K,20次方是1M,30次方是1G,40次方是1T,对于一个名字空间,Sawtooth 为其保留64位,从存储空间需求上讲,即使有一些位被用来做子空间划分,应该也够用了。在查找时,完全可以根据 Transaction 的名字找到它的存储位置,所以检索速度也会非常快。

我们可以认为,Sawtooth 就像一个原始的区块链,每向后一层都可以分叉,以树的形式组织数据存储,而不再是以线性的方式来组织数据存储。也可以把原始的比特币区块链理解为只有一个Transaction Family 的 Sawtooth。在完整的分析过 Sawtooth 以后,最应该记住的就是 Sawtooth 的存储结构,它其后的所有设计都是基于这一结构。

  • Merkle Hash Tree

Merkle Hash Tree 的特点是所有节点的值都是哈希值,每个哈希值是根据其子节点的哈希值计算出来的,所以任何一个节点和哈希值出现变化,它的上层节点的哈希值都会跟着变。

Sawtooth 采用 Radix Merkle Tree 结构做数据存储的好处就是给定 Block 名及类别,直接计算哈希值,就找到它的存储位置了。而且存储空间是隔离的,每个 transaction family 的存储空间和其它的都是分开的,互不影响。所以,从存储结构来看,基于 Sawtooth 的区块链天生是多条连的(Forked),很容易去解析它的分叉。

Sawtooth 的数据结构

Fabric 没有去严格定义数据结构,Sawtooth 的数据结构也没有什么值得特别提出的亮点。只要知道 Sawtooth 定义了 Transaction 包括Header 和 Payload 两部分即可,而 Sawtooth 要求不管是一个还是多个 Transaction 必须被封装在 Batch 中才可以提交给 Transactio n的 Processor ,或者说 Transaction Processor 只接受以 Batch 为最小单位的 Transactions 。同样地,Batch 也包括 Header 和 Payload 两部分,其关系如下图所示:

Sawtooth 的网络结构

如下图所示,Sawtooth 的一个节点可能由如下几个部件组成:Validator、Transaction Proc essor、REST API、以及 Client。Validator 是 Sawtooth 的核心部件,主要功能包括接收 Transaction 请求,并将其转发给相应的 Transaction Processor 来处理,根据 Transaction Processor 的处理结果,决定如何生存新的区块,如何给 Client 回显。Validator 还要与其他的 Validator 协同,以保持 Sawtooth 网络的全局状态一致。Transaction Processor 顾名思义就是用来专门处理某一类型 Transaction Family 的 Transactions 的 Processor 。

Client 需要按照 Transaction 和 Batch 规定的数据结构生成请求,REST API 则是标准化的网络传输数据格式。之所以说可能由这几部分组成,是因为对 Sawtooth 来说,只有 Validator 属于其固定结构,比如图中有 Validator1 和 Validator2 ,而 Validator2 就没有连接其他部件,而是只与 Validator1 相连。从构成角度看,一个 Sawtooth 网络可以只由一个 Validator 构成。从网络方面看,其他的 Validator 可以动态加入网络。从部件方面看,Transaction Processor 可以动态注册到 Validator ,然后 Client 提交相应 Transaction 就有对应的 Processor 来进行处理。网络节点和部件可以分别使用不同的端口来区分。这样,Sawtooth 网络就变成完全动态的了,每个组成部分都可以动态插拔。

接下来,我们先看看 Validator 的组成结构,Validator 的软件实现部分称为 Journal,如下图。从功能上看,Journal 包括 Completer、ChainController 和 BlockPublisher 三个主要部分。

当 Batch 被提交给 Validator 后,先被交付到 Completer ,它先检查是否 Batch 的所有依赖项都得到了满足。完整且满足依赖的 Batch 会被提交给 ChainController 。Sawtooth 的这种设计可以支持串行和并行的 Batch,注意这已经不是进程级并行了,而是线程级并行。接下来再看看 ChainController 是干什么的:

ChainController 需要完成4个工作:

  • 1)确定块的头在哪
  • 2)确定当前块在哪-先去 BlockCache 里找,再去 BlockStore 里找。
  • 3)验证块有没有损坏
  • 4)把新块写进区块链

写入新区块链后的发布工作则是由 BlockPublisher 完成。从图中可以看到,ChainController 和 BlockPublisher 本质上都是接口,具体的实现由更下层的共识(Consensus)机制完成,共识机制向上提供 BlockVerifier,ForkResolver 和 BlockPublisher 三个功能。

从整体上看,Validator 的结构比较简单。接下来再看看 Validator 之间是怎么连接起来的。Sawtooth 的 Validator 的网络连接方式如下图,可能会有点乱,同时解释地也不是很清楚,这里笔者的理解是:把它看做一个 Ad Hoc 网络,组网的过程完全就是模拟 Ad Hoc 网络路由节点发现的。开始的时候有初始(生成 Genesis block 的)节点,它可以发出广播包,问谁在它边上,可以按照设定的规则加入网络,如果有人应答就可以加入,然后这些节点继续广播,每个广播包只传播给距离自己1跳的 Validator 节点,这样网络很快就组成了。有新节点想加入也是这样,发广播包,看看自己周围有没有可以直连的节点,退出就无所谓了,反正少一个节点不影响网络。我们知道 Ad Hoc 网络的健壮性和灵活性都是非常高的,所以 Sawtooth 的 Validator 网络中任何节点都是可以动态加入或退出的,只要网络规模足够大,理论上,网络的健壮性是有保障的。

这里有两个关键问题其实没有说清。

  • 1)哪些 Validator 可以加入该网络
  • 2)Validator 接受哪些 client 提交的 Batch

这两个问题就构成了访问控制和隐私保护功能的核心,而 Fabric 花大力气实现的体系结构也正是为了回答这两个问题,稍后会详细说明,核心网络介绍完毕以后,会想到 Client 提交了 Transaction,那Transaction 执行与否?所以,还差一个事件机制来实现消息传递和回显功能。这里的事件机制要确定这么几件事:

  • 1)谁应该被告知事件—(广播?还是根据注册情况组播单播)
  • 2)事件应该包括什么—(消息格式-收据(Transaction Receipt))
  • 3)事件在什么情况下,或什么时候才算有效—(放在 Transaction Receipt Store 中,通知发起 Transaction 的 client 来拿)

下图是 Sawtooth 的事件机制示意图,它把技术实现和组件名称混到一起,看起来也比较乱。大体的意思是左上部是事件子系统用 Zero message queue 的技术实现,其特点是在需要的时候可以随时创建,右上部是写好的类库,注册后,只要满足约束就可以调用它。下部说的是 Transaction Processor 调用具体的 Handler 处理 Transaction 后会告诉 ChainController 的 Scheduler 和 Executor 执行 Transaction 的结果情况,ChainController 除了把新的 block 写到它应该在的地方之外,还会把 Transaction 的 Receipt 放到一个叫 Transaction Receipt Store 的地方,这时候 ChainObserver (Client 注册后产生的一个部件)就会告诉 Client, Transaction 执行完了,来拿收据吧。

下面是一些事件的例子,可以帮助我们理解事件的格式:

 1Example events generated by BlockEventExtractor:
 2Event {
 3  event_type = "sawtooth/block-commit",
 4  attributes = [
 5    Attribute { key = "block_id"value = "abc...123" },
 6    Attribute { key = "block_num"value = "523" },
 7    Attribute { key = "state_root_hash"value = "def...456" },
 8    Attribute { key = "previous_block_id"value = "acf...146" },
 9  ],
10}
11
12
13Example events generated by ReceiptEventExtractor:
14// Example transaction family specific event
15Event {
16  event_type = "xo/create",
17  attributes = [Attribute { key = "game_name"value = "game0" }],
18}
19
20// Example sawtooth/block-commit event
21Event {
22  event_type = "sawtooth/state-delta",
23  attributes = [Attribute { key = "address"value = "abc...def" }],
24  event_data = <bytes>
25}

Sawtooth的访问权限控制

Sawtooth 的权限(Permissions)机制应该参考过 Fabric。主要功能包括网络权限的设置(哪些 Validator 可以加入这个网络),和 Transaction 权限设置(哪些 client 提交的 Batch 可以被 Validator 执行)两种。和 Fabric 一样的是,Sawtooth 也需要配置文件,如果所有功能全部用配置文件完成则称为 Off-Chain transactor  Permission,通常来说小规模网络,极限情况下,只有一个节点的网络完全可以使用 Off-Chain 的方式实现。在 Off-Chain Permission 中,权限是静态设置的。在配置文件 validator.toml 中,直接配置:

[permissions]

ROLE = POLICY_NAME

Policy file:

PERMIT_KEY <key>

DENY_KEY <key>

这里的 ROLE,POLICY_NAME 暂不解释,key 一般是一个公钥,PERMIT_KEY 和 DENY_KEY 就将它理解为一个 bool 值,一个是1,一个是0,含义就是允许不允许。

和 Fabric 不一样的地方是,Sawtooth 还有一种配置方式叫 On-Chain transactor Permission 。就是在区块链上直接设置访问权限,还专门为此设置了一个叫 Identity 的 Transaction Family 。这样 transactor Permission 就有自己的存储空间,其当前值也好,变化也罢,所有节点都可以同步过去,不会存在各个节点配置文件不一样导致系统出错的可能性。

接下来具体看下 Identity。Identity Namespace 以 key-value 对的形式存储 roles,key 是 role name,value 是 policy。所有的 role 都以 transactor 为前缀。比如下面:

transactor.SUB_ROLE = POLICY_NAME

首先,第一个问题是开始谁可以设置访问权限。和 Fabric 例子中类似,机构 R4 通过网络配置文件设置访问权限一样。在 Sawtooth 中,理所当然的应该由创始区块的生成者来设置初始权限。它执行如下命令来设定允许给别人授权的人的公钥:

sawset proposal create sawtooth.identity.allowed_keys=00000

这里的00000是创始区块的生成者自己的公钥,那现在就它自己可以给别人授权。这个类似于 Fabric 里设定,公钥设定以后可以利用 identity-tp 进行授权,也可以继续用 sawset proposal create 命令让其他 Validator 有权做网络或者 Transaction 授权。proposal 这个子命令其实就能猜到 Sawtooth 设计访问权限的时候肯定是参考了 Fabric 的。

具体的 Transaction 授权命令的例子如下:

sawtooth identity policy create policy_1 “PERMIT_KEY *”,这个的意思是创建一个叫 policy_1 的策略,对所有人都是允许的,也就是谁都可以提交 Transaction ,注意这仅仅是个策略,还可以定义其他的策略,相当于 Fabric 里的 Deploy 而不是 Invoke 。可以调用 sawtooth identity policy list,查询当前有哪些策略,比如在执行了刚才的命令后,会得到如下回显:

$ sawtooth identity policy list

policy_1:

Entries:

PERMIT_KEY *

接下来执行如下命令:

$ sawtooth identity role create transactor policy_1

就会把 transactor 的策略设置为 policy_1。换句话说,这时,就真正让 policy_1 生效了,类似于 Fabric 里的 Invoke。然后可以调用sawtooth identity role list,查询当前角色的状态:

$ sawtooth identity role list

transactor: policy_1

上边我们都用 transactor 为例子,其实 role 可以有如下几种:

default、transactor、transactor.transaction_signer、transactor.transaction_signer.{tp_name}、transactor.batch_signer。

意思其实从字面上能看出来,这里 transactor 可以是 organization,一个 transactor.batch_signer 可以是一个 organization 下边的部门,transactor.transaction_signer 可以是该部门的一个用户,如果有好多 tp 的话,该用户可以只具有其中某些 tp 的执行权限。

比如,我们现在自己写了一个新的 tp 叫 supply_chain,新定义了两个用户,一个的公钥是12345,另一个的公钥是23456,我们希望这个 tp 只有这两个新用户可以运行,这时我们就可以执行命令:

sawtooth identity policy create policy_2 “PERMIT_KEY 12345” “PERMIT_KEY 23456”

sawtooth identity role create transactor.transaction_signer.supply_chain policy_2

网络权限设置和 tp 执行权限设置差不多,比如有个 Validator 对外的公钥是00001,然后执行如下命令,它就不能加入网络了:

$sawtooth identity policy create policy_3 “DENY_KEY 00001”

$ sawtooth identity role create network policy_3

$ sawtooth identity role list

network: policy_3

Fabric 和 Sawtooth 的比较

相信看完了 Fabric 和 Sawtooth 的介绍,大家对这两个项目都有了自己的认识。笔者再谈一下个人对这两个项目的理解。

首先,从背景上看,Fabric 是脱胎于 Ethereum 的,或者说能在 Fabric 上看到 Ethereum 的影子,而 Sawtooth 已经看不到 Ethereum 的任何痕迹了。反而,个人觉得 Sawtooth 更加纯粹一点,它就是一个有共同起点的 比特币区块链,只是比特币没有不同 Transaction 的概念,而 Sawtooth 把 Transaction 按照用途分类,且允许用户根据需要自己定义新的 Transaction (这个概念是 Ethereum 提出来的)。

从体系结构角度看,我认为 Sawtooth 明显优于 Fabric 。Fabric 像是针对特定问题的一个专用解决方案,而不像一个通用架构。Sawtooth 可以认为是一个通用架构,然后根据需求变为一个专用解决方案。从访问控制角度看,Fabric 像是根据实际情况建设了一套管网,让涉及隐私的数据只能在其中运行。Sawtooth 则更像是在一套管网上加装了阀门,通过阀门来控制数据的流向。这可能和 IBM 以及Intel 的业务特点和公司文化息息相关。我的印象中,IBM 是一家咨询公司,专门针对企业级用户设计解决方案。Intel 是处理器公司,不管你的业务是什么样的,它提供通用中央处理器,让你能根据自己的需要配置成自己的专用解决方案。

当然,二者也有一些具体的差异:Fabric 中,多个节点收到相同的输入后分别独立执行,以期得到一致的结果。Sawtooth 的 SGX 和基于 SGX 的 PoET 验证的是在一台机器上的执行结果,没有再让每个节点都去执行一遍,而是一个执行完了以后去和别的同步结果。二者的假设不同,效率上也有差别。Fabric 的权限控制依赖形成 channel 这种体系结构,Sawtooth 的权限控制通过 Transaction 本身进行设置。或者说,Fabric 只有特定的人能看,但能看到特定范围内的全部。Sawtooth 所有人都可以看,但 Transaction 的 Permissions 限制了能看什么。Fabric 的 orderer 完成 Transaction 排序,可以实现进程级并行。Sawtooth 的排序是在 batch 里指明依赖关系,通过Completer 排序实现线程级并行。

对 Fabric 来说,要设计它时,大家认可的网络结构就是 Ethereum 了,怎么能稍作修改,实现隐私保护和访问控制是它的设计目标。Sawtooth 没这种包袱,可以重新设计网络。所以,我感觉 Fabric 更像是一个过渡性的产品。从我的角度看,Sawtooth 的结构设计的比较精巧,可扩展性强,这是它比 Fabric 强的地方。但它还可以借鉴 Fabric,增加类似 CA 的机制确保用户可以被识别,也应该增加权限配置的灵活性,比如引入 ABAC,等等。不过,现在这样就已经非常不错了。

推荐阅读:

技术专栏丨Fabric和Sawtooth技术分析(上)

技术专栏丨基于Core ML的通用性机器学习开发框架探索

干货分享丨研发代码质量管理技术最佳实践

技术专栏丨Redis分布式锁的小坑踩一踩

举个例子丨什么是量子计算机?比常规计算机强在哪里?

作者:YK Sugi

译者:赵磊

原文链接:http://t.cn/EZAElk0

本文作者访问了加拿大温哥华的一家名为 D-Wave System 的制造尖端量子计算机的公司,并在那里学习了很多关于量子计算机的知识。

在这篇文章中,作者将通过一个简单地例子让没有物理或计算机科学知识地小伙伴也能搞懂什么是量子计算机,欢迎分享~

1什么是量子计算机

量子计算机是一种使用量子力学原理进行计算的计算机,它能比常规计算机更有效地执行特定类型的计算。

听的是不是有点云里雾里?不是说好了没有物理学或计算机科学知识也能听懂吗?别急,这里将通过一个简单的例子来告诉大家,它到底是什么。

为什么解释什么是量子计算机,首先就需要解释一下常规(非量子)计算机。

2存储信息方式有何不同

一台普通的计算机以 0 和 1 的 序列存储信息,不同类型的信息,如数字、文本和图像都可以使用这种方式表示,这种由 0 和 1 组成的序列中的每个单元都被成为比特位,所以,比特位可以设置为 0 或 1。

量子计算机不使用比特位来存储信息,相反,它使用一种叫量子位的东西,每个量子位不仅可以设置为 1 或 0,还可以设置为 1 和 0。那这到底意味着什么呢?这里用一个简单的例子来解释这个问题:

假设我们在经营一家旅行社,需要把一群人从一个地方搬到另一个地方。

为了简单起见,假设现在只需要移动3个人—— Alice、Becky 和 Chris。我们为此预定了两辆出租车,但想知道谁上了哪辆出租车。另外我们也得到了关于谁和谁是朋友,谁和谁是敌人的信息。

这里我们假设:

  • Alice 和 Becky 是朋友
  • Alice 和 Chris 是敌人
  • Becky和 Chris 是敌人

我们的目标是把这3个人分成两组并实现以下两个目标:

  • 最大限度地增加共享同一辆车的朋友对的数量
  • 最大限度地减少共享同一辆车的敌人对的数量

这是这个问题的基本前提。我们首先考虑如何用常规计算机解决

3用常规计算机去解决问题

要用普通的非量子计算机解决这个问题,首先需要弄清楚如何用比特存储相关信息。

我们把这两个出租车标记为出租车 1 号和出租车 0 号。

然后,可以用3个比特位表示谁进入哪辆车。

例如,我们可以通过将这3位设为0、0 和 1 来表示:

  • Alice 在 0 号出租车
  • Becky 在 0 号出租车
  • Chris 在 1 号出租车

因为每个人有两种选择,所以有 2x2x2 = 8 种方法将这群人分到两辆车上。

这里列出了所有可能的情况:

A | B | C

0 | 0 | 0

0 | 0 | 1

0 | 1 | 0

0 | 1 | 1

1 | 0 | 0

1 | 0 | 1

1 | 1 | 0

1 | 1 | 1

使用3个比特位,就可以表示这些组合中的任何一种。

计算每个配置的得分:

现在,使用常规计算机,我们如何确定哪种配置是最好的方案呢?

为此,我们需要定义如何计算每个配置的得分。这个分数将代表每个解决方案达到我前面提到的两个目标的程度:

  • 最大限度地增加共享同一辆车的朋友对的数量
  • 最大限度地减少共享同一辆车的敌人对的数量

我们简单定义分数如下:

给定配置的分数 = 共享同一辆车的朋友对数 – 共享同一辆车的敌人对数

例如,假设 Alice、Becky 和 Chris 都乘坐出租车1号。用三个比特表示为 111。

在这种情况下,只有一对朋友共用一辆车—— Alice 和 Becky。

但是却有两对敌人共用一辆车——Alice 和 Chris 以及 Becky 和 Chris。

所以,这个配置的总分为 1 – 2 = -1。

解决问题:

有了这些,我们终于可以着手解决这个问题了。

对于一台普通的计算机,要找到最好的配置,需要遍历所有配置,看看哪个达到了最高分。

构建的表格如下:

A | B | C | Score

0 | 0 | 0 | -1

0 | 0 | 1 | 1 <- 最佳解决方案之一

0 | 1 | 0 | -1

0 | 1 | 1 | -1

1 | 0 | 0 | -1

1 | 0 | 1 | -1

1 | 1 | 0 | 1 <- 另一个最佳解决方案

1 | 1 | 1 | -1

这里有两个正确的答案——001 和 110,都达到了 1 分。

这个问题相当简单。但是随着越来越多的人参与到这个问题中来,用一台普通的电脑很快就会变得难以解决。

可以看到如果是3个人,需要遍历8种可能的配置。

如果有4个人呢?我们需要遍历 2x2x2x2 = 16 个配置。

对于n个人,我们需要通过遍历2的n次方个配置来找到最佳解。

所以,如果有100个人,我们需要遍历:

2¹⁰⁰ ~= 10³⁰ 个配置

因此这是常规计算机根本无法解决的问题。

4用量子计算机去解决问题

那么如果我们用量子计算机来解决这个问题呢?

让我们回到把3个人分到两辆出租车的例子。

正如我们前面看到的,这个问题有8种可能的解决方案:

A | B | C

0 | 0 | 0

0 | 0 | 1

0 | 1 | 0

0 | 1 | 1

1 | 0 | 0

1 | 0 | 1

1 | 1 | 0

1 | 1 | 1

用一台普通的计算机,用3个比特位,一次只能表示其中一个解——例如 001。

然而,使用量子计算机,通过3个量子位,我们可以同时表示所有8个解。

关于这个说法的确切含义存在争议,但作者的看法是这样的:

首先,来看这3个量子位中的第一个量子位。当将其设置为 0 和 1 时,就好像创建了两个并行世界。

在其中一个平行世界中,量子位被设置为 0,而在另一个平行世界中为1。

现在,如果再把第二个量子位也设为 0 和 1 呢?就像是创造了4个平行世界。

在第一个平行世界中,两个量子位被设置为 00,第二个平行世界中是 01,第三个平行世界中是 10,第四个平行世界中是 11。

类似的如果将这三个量子位都设置为 0 和 1 ,就会创建8个平行世界——000、001、010、011、100、101、110 和 111。

虽然这是一种奇怪的思考方式,但它是解释量子比特在现实世界中的行为的正确方式之一。

现在,当对这三个量子位进行某种计算时,实际上是在同时对这8个平行世界进行同样的计算。

因此,我们可以同时计算所有解的分数,而不是按顺序遍历所有这些可能的解。

有了这个特殊的例子,理论上量子计算机可以在几毫秒内找到最好的解——001 或 110,正如我们之前看到的:

A | B | C | Score

0 | 0 | 0 | -1

0 | 0 | 1 | 1 <- 最优解之一

0 | 1 | 0 | -1

0 | 1 | 1 | -1

1 | 0 | 0 | -1

1 | 0 | 1 | -1

1 | 1 | 0 | 1 <- 另一个最优解

1 | 1 | 1 | -1

实际上,要解决这个问题只需要让量子计算机去做两件事:

  • 所有可能的解都用量子位表示
  • 将每个可能的解转化成分数的函数。在本例中,这个函数计算共享同一辆车的朋友对和敌人对的数量。

具备了上述两个条件,量子计算机将在几毫秒内给出其中一个最好的解决方案。在本例中,分数为 1 的是 001 或 110。

现在从理论上讲量子计算机每次运行都能找到最好的解。

然而,实际上在运行量子计算机时有可能存在错误。所以,它可能会找到次优解,次次优解,等等。

随着问题变得越来越复杂,这些错误变得越来越突出。

因此,在实践中可能需要在量子计算机上运行相同的操作数十次或数百次。然后从结果中选出最优解。

量子计算机的改进之处:

即使有一些缺陷,但量子计算机也不会遇到常规计算机那样的计算规模问题。

当有3个人需要分到两辆车上时,需要在量子计算机上执行的操作数是1。这是因为量子计算机同时计算所有情况的分数。

当有4个人的时候,操作的次数仍然是 1。

当有100人的时候,操作的次数仍然是 1。仅仅一次操作,量子计算机就能同时计算出2¹⁰⁰ ~ = 10³⁰ 种情况的分数。

而正如之前所说,在实践中最好运行量子计算机几十次或几百次,然后从得到的结果中选出最好的结果。

5总结

D-Wave Systems 最近推出了一个与量子计算机交互的云环境。

如果你是一名开发人员,并且想使用量子计算机,可以尝试这种简单的方法:

  • 名称:Leap
  • 地址:https://cloud.dwavesys.com/leap

可以免费使用它来解决很多问题,并且在注册后还可以看到很多关于量子计算机的相关教程。

备注:在本文中,作者使用术语“常规计算机”来指代非量子计算机。然而,在量子计算行业中,非量子计算机通常被称为经典计算机

想成为数据科学家?这5个基本统计学概念不能不知道!

译者:TalkingData 赵磊

原文作者:George Seif

原文链接:t.cn/EzFQvOi

如果说数据科学是一门艺术,那统计学可谓是这门艺术的敲门砖,从高层次的角度来看,统计是利用数学对数据进行技术分析。一个很基本的数据可视化如条形图,就能解读出一些高级的信息。

而如果通过统计学,我们就能以一种更加以信息驱动和更有针对性的方式来操作数据,所用到的数据的方法,可以帮助我们对数据形成具体的结论,而不是靠拍脑袋的猜测。

通过使用统计学,我们可以更深入细致地去了解数据的构造,并基于该结构,还可以用其他数据科学来获取更多的信息,将结果最大化。本文将和大家分享数据科学家们需要了解的5个基本统计概念,以及如何更有效地运用它们,希望对小伙伴们有所帮助。

//统计特征//

统计特征大概是数据科学家种最常用的统计概念了,它通常是数据科学家们在研究数据集时应用的第一种统计技术,包括偏差、方差、平均值、中位数、百分位数等等。比较容易让人理解以及在代码中去实现,如下图:

一个简单的箱型图

中线是数据的中位数,由于中位数对离群值的鲁棒性更强,因此中位数比平均值用得更多。第一个四分位数本质上是第25百分位数,表示数据中25%的点低于这个值。第三个四分位数是第75百分位数,表示数据中75%的点都低于这个值。最小值和最大值表示数据范围的上、下端。

这个箱型图完美地阐述了我们能用基本统计特征做什么:

  • 当框图很短时,它意味着许多数据点是相似的,因为在小范围内有许多值;
  • 当框图很长时,它意味着许多数据点是完全不同的,因为这些值分布在一个较广的范围内;
  • 如果中值更接近底部,就可以知道大多数数据的值更低;
  • 如果中值更接近顶部,就可以知道大多数数据都有更高的值;
  • 基本上,如果中值线不在方框中间,那么它就表示数据有偏斜;
  • 是否有长尾?这意味着你的数据有很高的标准差和方差,说明这些值是分散的,高度不同。如果在盒子的一边有长尾而在另一边没有,那么数据可能只在一个方向上有很大的变化;

以上这些信息都来自一些简单的、容易计算的统计特征,当需要对数据进行快速而有效的查看时,可以尝试这些方法。

//概率分布//

我们可以将概率定义为某个事件发生的概率百分比。在数据科学中,通常在0到1之间进行量化,0表示确信不会发生,1表示确信它会发生。概率分布是一个函数,表示实验中所有可能值的概率。

详情请看下面的图表:

均匀分布是本文三个分布中最基本的分布,它只有一个只出现在某个范围内的值,而超出这个范围的任何值都是0。通常,它是一种“开关”分布。我们也可以把它看作是一个有两个类别的分类变量:0或其他值。分类变量可能有多个非0的值,但我们仍然可以把它想象成多个均匀分布的分段函数。

正态分布,通常被称为高斯分布,由均值和标准差定义。均值在空间上平移分布,标准差控制分散程度。与其他分布的重要的区别(比如泊松分布)是,其所有方向上的标准差都是一样的。

泊松分布与正态分布相似,但增加了偏斜因子。在偏态值较低的情况下,泊松分布会像正态分布一样向各个方向均匀发散。但当偏度值较大时,我们的数据在不同方向的发散会有所不同;在一个方向,它将非常分散,而在另一个方向,它将高度集中。

虽然有很多的分布可以深入研究,但上述三个分布已经可以为我们带来很多探索的价值,比如:可以用均匀分布快速地查看和解释分类变量。如果看到一个高斯分布,就能知道可以用很多算法去处理它。有了泊松分布,就必须小心谨慎地选择一种对空间发散的变化具有鲁棒性的算法。

// 降维//

降维这个术语很容易理解:我们有一个数据集,希望减少它的维数。在数据科学中,它是特征变量的数量。

请看下面的图表:

降维

立方体代表数据集,它有三个维度,总共有1000个点。虽然1000个点的计算在今天很容易处理,但是,更大范围的点我们仍然会遇到很多问题。若是仅从二维的角度来看数据,例如从立方体的一边可以看到,划分所有的颜色很容易,通过降维,我们可以将三维数据投射到二维平面上。这有效地将我们需要计算的点数减少了100,大大节省了计算量。

特征剪枝是另外一种降维的方法。通过特征剪枝,可以删除对分析不重要的任何特征。例如,在研究数据集之后可能会发现在10个特性中,7个特性与输出强相关,而其他3个特性的相关性很低。那么,这3个低相关特性可能不值得计算,可以根据分析在不影响输出的情况下将它们删除。

当前用于降维的最常见技术是PCA,它本质上是创建了特征的向量表示,显示它们对输出的重要性,比如相关性。PCA可以用于上面讨论的两种降维方式。

过采样和欠采样是用于分类问题的技术。有时分类数据集可能会严重倾斜到一边。例如,类1有2000个样本,但类2只有200个。这将对很多常用于建模并预测的机器学习技术带来影响,但过采样和欠采样可以改变这一点。

示例请看下面的图表:

欠采样与过采样

上图中蓝色类比橙色类拥有更多的样本,在这种情况下,有两个预处理选项可以帮助于机器学习模型的训练。

欠采样意味着将只从多数类中,只使用与少数类样本数相同的数量,并且这个方案应当保证采样后类别的概率分布与之前相同。操作并不复杂,其实只是通过取更少的样本来平衡数据集。

过采样意味着将创建少数类的副本,以便拥有与多数类相同的样本。创建副本时应当保证少数类的分布不变。这个方案只是把我们的数据集变得更均衡,而不是得到更多的数据。

//贝叶斯统计//

如果要充分理解为什么要使用贝叶斯统计,那么首先需要了解频率统计不足之处。频率统计是大多数人听到“概率”这个词时会想到的统计方法。它应用数学来分析某些事件发生的概率,具体来说,我们使用的数据都是先验的。

举例说明:一个骰子掷出6的概率是多少,大多数人会说是1 / 6。确实,如果我们做频率分析,会通过一些数据比如某人掷骰子10000次,然后计算每个数字出现的频率;大概是1 / 6

但如果骰子是经过改造的,落地后总会是6的那面朝上呢?频率分析只考虑了先验的数据,并没有考虑骰子被改造过这个因素。

贝叶斯统计确实考虑到了这个问题,可以用贝叶定理来说明这一点:

方程中的概率P(H)是频率分析;表示根据之前的先验数据,事件发生的概率是多少。方程中的P(E|H)被称为似然,本质上是根据频率分析得到的信息的条件下,我们得到的结论是正确的概率。例如,滚动骰子10000次,而前1000次全部得到6,就可以认定骰子是被改造过的,P(E)是实际结论成立的概率。

如果频率分析得很好,那么就可以得出:对于骰子6的一面朝上的猜测是正确的,即考虑了骰子是被改造的。

从方程的布局可以看出,贝叶斯统计考虑了所有的因素。当觉得之前的数据不能很好地代表未来的数据和结果时,就可以去使用贝叶斯统计。

技术专栏丨基于Core ML的通用性机器学习开发框架探索

Core ML 概览

机器学习不仅是目前最火的技术,同时也是人工智能最核心的内容。机器学习是一种能让计算机无需不断被显示编程,而自我学习的人工智能技术。不通过某个具体的编程算法,而是在大量的数据样本中找到一个合适的模式或者规律,从而让计算机能够不断的自我发展和完善自我的算法。

一般情况下,机器学习模型都是庞大且复杂的,截止到目前,能够直接进行模型训练的方式和架构还暂未出现,当前的方法是将训练好的模型文件应用在移动设备上,使用预制的框架加载与使用模型,或者通过API 的方式联网远程预测等。

相对来说,通过远程预测的方式可以保证安全性,但却严重依赖网络环境,为了避免不确定的网络环境所带来的预测失败或无法预测等异常情况,可以将模型文件直接应用在移动设备上,这样不仅能够保证时效性,也无需再依赖网络环境,这种方法对于推理预测来说有了保证。

自 iOS 11 开始,苹果在 iOS 系统中引入了一种全新的,直接依附于硬件平台的机器学习框架——Core ML,该框架使机器学习模型在 iOS 系统平台下预测推理可以快速并易于实现。借助 Core ML,可以将已训练好的机器学习模型,集成到自己的应用当中,以实现智能化的应用程序,提升用户体验等。

已训练模型 (trained model),指的是对一组训练数据应用了某个机器学习算法后,所生成的一组结果。举个例子,通过移动设备上附带的传感器数据来训练一个能够识别用户行为类型(走、跑、乘车等)的模型,将该模型应用于应用程序中后,该模型可以对用户使用移动设备时所做出的行为进行预测(该模型目前已在 TalkingData SDK 中实现并应用)。

在iOS体系中,Core ML 是领域特定 (domain-specific) 框架和功能的基础所在。Core ML 为 Vision 提供了图像处理的支持,为 Foundation 提供了自然语言处理的支持(例如 NSLinguisticTagger 类),为 GameplayKit 提供了对学习决策树 (learned decision tree) 进行分析的支持。Core ML 本身是基于底层基本类型而建立的,包括 Accelerate、BNNS 以及 Metal Performance Shaders 等。

Core ML 针对设备的性能进行了优化,最大限度地减少了内存占用和功耗。因其在设备上运行有着严格要求,这不仅保护了用户数据隐私,而且当网络连接丢失时,还能够保证应用能正常工作和响应。

Core ML的缺点

Core ML本身是非常优秀的,它使得将机器学习甚至深度学习模型移植到移动设备上变为了可能。但是不得不说的是,Core ML 也有一定的局限性:

  • Core ML 目前仅能进行预测,无法进行模型的训练。训练模型只能在 PC 上或者云上训练,之后再转为 Core ML 支持的格式才可使用;
  • Core ML 目前所支持的深度学习隐藏层运算函数有限;
  • Core ML 目前的方式不利于模型的更新。当模型集成进应用程序后,如果要更新模型或模型发生了异常,只能通过线下更新模型,并且之后还需要重新提交应用,进行审核;
  • Core ML 目前的模型接口函数的调用,缺少统一性的 API 管理,大多数的模型在移植进 iOS 应用程序后,所产生的 API 大同小异,但 Xcode 都会产生一整套重复的接口文件等。

鉴于以上问题,经过调研和不断的试验,最终找到了一个较为合适,但不敢说是完美的方案。

通用性的模型加载预测框架

在 iOS11 中,所有的预训练模型 .model文 件,在 App 中的存在格式都是经过 Xcode 自动转换过的 .mlmodelc 文件,该文件是 Core ML 框架加载和使用的参数文件,本项目也正是借助此特性,在线下载已经训练好的预训练模型,然后使用 Core ML 提供的 API 来进行文件转换,之后进行加载使用。

这样避免了应用程序最初就带有预训练模型,避免了初始应用程序包过大,给用户造成下载应用程序的忧患。根据上述调研结果,设想该框架的整体架构如下:

通过 URL 请求,下载经过压缩的预训练模型,在压缩之前,模型已经是完整的符合 Core ML 要求的 .model 格式。下载完成后,进行文件解压缩,同时使用 Core ML 提供的模型编译 API ,完成对 .model 模型文件的编译,产生 Core ML 直接可以使用的 .mlmodelc文件并存储在本地磁盘,等待随时的加载使用。

当开发者调用该框架启动 API 后,该框架使用 Core ML 提供的模型加载 API 预加载模型到内存,开发者根据自己的需求在适当的时机将符合格式的数据传递给模型预测 API,模型进行预测推理后给出结果,开发者根据结果实现自我业务逻辑等。

工作流程

经过试验后,整理出了一套可以直接在应用程序中使用的开发框架,开发者不需要过多的设定,仅仅需要在应用程序中配置好所需要使用的模型下载地址,之后在合适的时机调用框架的启动接口即可。当一个机器学习任务来临的时候,调用该框架的预测接口,传入数据(例如图像)即可获得预测结果,直接使用。

使用示例

以 MobileNet 图像识别模型为例,使用Swift进行相关代码编写。

  • 在项目中新建一个 plist 文件,假设命名为 MobileNet-Model.plist ,定义 MobileNet 模型基本信息与下载地址,如下图:

  • 初始化框架对象:

  • 启动框架并传入模型定义plist:

  • 传入数据进行预测与结果使用:

示例结果:

总 结

通过该框架,可以减轻开发者繁重的机器学习模型集成压力,开发者只需要关注模型所需数据的格式即可快速开发有关机器学习任务。

目前该框架可用于大多数的图像分类模型,基本用法同上述示例,接下来我们将进一步的扩展和优化该框架,使其能够适应更多的模型,让移动端的机器学习应用开发更加的得心应手。

必须收藏丨万字长文,带你了解跨平台移动应用开发工具

TalkingData 张永超 译

原文链接:
https://instabug.com/blog/cross-platform-development/?utm_source=reddit&utm_medium=social&utm_content=cross_platform_development

在如今的电子世界当中,运行着各类操作系统,如何让应用适配每个操作系统平台,是开发者们一直在思考的问题。因为平台、技术、工具的有多样性,让适配变得无比的困难与繁杂,甚至需要花费大量的时间和资金去进行研究。本文将介绍目前比较流行的可以开发跨平台应用的开发工具,希望能够帮助开发者们实现全平台覆盖。

本文较长,其中大量资源网址值得收藏!

移动应用开发概述

Web应用

Web应用是运行在网页上并存储在远端服务器上的应用,此类应用通过设备上的网页浏览器加载与展示。

即便在某些情况下网页应用运行良好,但仍无法避免会出现一些问题,比如需要连接到网络才能在设备上运行,因为所需的资源并未存储在本地设备上,而是在远端服务器上。另外,此类应用无法在移动商店上直接使用,导致用户很难找到和下载使用。

Hybrid跨平台应用

Hybrid应用又称为混合应用,此类应用基本上使用每个平台的浏览器内置组件进行包装和打包,以达到在每个平台上运行的目的,应用就像该平台上的Native应用一样。混合应用主要使用的语言为HTML5、JavaScript和CSS。

混合跨平台应用解决了Web应用面临的问题,因为混合应用在本地运行时无需网络连接,而且还能在应用商店上发布,可以让用户轻松找到,从而增强应用的可发现性、增加用户量等。

混合跨平台应用开发工具:Apache Cordova、Ionic、Adobe PhoneGap等。

Native应用

原生应用是为了在特定平台或操作系统上工作而开发的应用。

对于iOS来说,开发者使用的是Swift或Objective-C编写iOS应用,而对于Android来说,开发者使用的是Java或Kotlin编写Android应用。从移动开发工具来看,iOS开发者经常使用Apple的Xcode或者第三方的AppCode等工具,而Android开发者经常使用Android Studio作为它们的主力开发IDE。

Native 跨平台应用

原生跨平台工具允许开发者编写一次代码,然后将该代码转换为适配多个操作系统的本地代码,让开发者以最小的成本在不同的平台上发布移动应用。原生跨平台应用是混合应用和本地应用的完美结合,不仅提供了混合应用的代码重用功能,而且性能也与本地应用类似。

原生跨平台应用开发工具:React Native、Xamarin、Titanium等。

跨平台移动应用开发

跨平台移动应用开发是创建可以使用单个代码库,在多个平台上部署或发布的移动应用开发过程,跨平台移动应用开发无需使用每个平台的对应的本地技术去进行多次开发。

跨平台开发有以下优点:

  • 可重用代码:跨平台开发工具允许只编写一次代码,然后将代码导出到需要操作的系统和平台上,无需为每个平台单独编写创建代码;
  • 便利性:跨平台开发工具能够省去学习许多编程语言的麻烦,开发者只需要理解领会一种语言即可;
  • 可维护代码:当需要修改或更新应用时,开发者只需更新一个代码库,就可以将更新同步反映在平台所有的应用上;
  • 成本效率:跨平台开发可以让单个开发团队能够在多个平台上进行工作,且大多数的跨平台开发工具都是免费的。
  • 市场覆盖率:通过多平台发布应用,可以让其增加曝光量,提升用户基数,从而提高投资回报率和经济利益。

虽然跨平台开发工具拥有很多优势,但在某些场景下的缺点也相当明显:

  • 性能:即便一些跨平台开发工具提供了接近本地应用的性能,但仍有不足,如果所开发的应用属于最高优先级,不建议使用跨平台开发工具。
  • 3D和图形:与性能上的缺点类似,跨平台开发工具无法提供最佳图形和最佳的用户体验,且无法访问核心OS库(如图形),如果所开发的应用严重依赖于图形,比如移动游戏类应用就不建议使用跨平台开发工具。
  • 单平台应用:如果所开发的应用尽在单一平台(如iOS或Android)上发布,那么还是应该使用本地开发的应用,在这种场景下,只需要一个团队使用一种技术即可,没有必要去损失性能。
  • 特定与平台的功能:虽然跨平台开发工具提供了不同平台之间共享的许多基本功能,但它们可能缺少Apple、Google和Microsoft的操作系统上提供的某些特定功能。
  • 特定与设备的功能:跨平台开发工具可以让开发者访问的不同功能,如相机或GPS,但如果所开发的应用需要直接访问和处理设备的硬件,本地开发应用是更好的选择。
  • 更新延迟:在一些特定平台发布更新时,可能需要等一段时间才能在所有平台开发工具中反应这些更新。

跨平台开发技术栈

虽然跨平台开发工具可以帮助开发者节省学习不同技术的时间和工作量,但仍然需要熟练掌握每种工具,使用的技术有:

  • React Native:JavaScript(JSX)、ES6、React.JS
  • Xamarin: C#
  • Cordova: HTML、CSS 、JavaScript

常用跨平台开发工具

  • Ionic
    地址:https://ionicframework.com/
  • Adobe PhoneGap
    地址:https://phonegap.com/
  • Titanium
    地址:
    https://www.appcelerator.com/Titanium/
  • Framework7
    地址:http://framework7.io/
  • Apache Weex
    地址:https://weex.apache.org/
  • Flutter
    地址:https://flutter.io/
  • Native Script
    地址:https://www.nativescript.org/
  • Jasonette
    地址:http://jasonette.com/
  • ManifoldJS
    地址:https://github.com/pwa-builder/ManifoldJS

三大主流跨平台开发工具

React Native

React Native是由Facebook基于其React JavaScript库创建的跨平台本地移动应用开发框架。主要使用JavaScript与JSX(JavaScript的扩展),ES6(ECMAScript 6),JavaScript的主要更新(包括许多新功能)和React.JS(用于构建用户界面的JavaScript库)。

React Native允许开发者使用React Native组件构建移动应用,然后再将其编译为本地应用,这些应用几乎与使用本地工具编写的应用完全相同。

React Native的优点

使用React Native进行跨平台移动应用开发的优点包括:

  • 可重用代码:可开发应用并从单个代码库将其导出到多个平台上。
  • 应用商店: 可以在各个平台的应用商店中发布应用。
  • 性能:React Native可将应用编译为本地应用,这与使用本地工具创建的应用几乎完全相同,使其比必须在特定于平台的Web组件中运行代码的混合应用更快。
  • 本地UI组件:React Native允许开发者使用React Native UI组件创建视图,这些组件被编译为特定于平台的UI组件,与使用HTML标记的其他跨平台工具不同。通过现成的组件,可以节省大量的时间。
  • 热重新加载:React Native中提供一项允许更改代码在iOS和Android应用中立即生效的功能,可以进行可视化更改。
  • 测试:调试React Native应用非常容易,因为它发布了本地应用版本,可以使用Expo这样的工具在物理设备上进行测试,无需在Xcode或Android Studio中打开它们。
  • 本地代码:与大多数其他跨平台开发工具不同,React Native允许开发者单独修改已发布的本地应用,它可以选择在React Native代码和本地代码之间进行组合,无论是Swift,Objective-C,或者是Java。如果想使用特定于平台的代码为不同平台实现单独的可视组件,就非常有用。
  • 可靠性:React Native由Facebook创建,许多世界顶级移动应用都在使用React Native,比如Facebook,Instagram,SoundCloud和Skype。
  • 免费:开源。

React Native的缺点

虽然React Native是目前最好的跨平台开发工具之一,但React Native仍然具有一些缺点:

  • 新技术:学习JSX和ECMAScript并不是一件容易的事,可能比其他熟悉的技术(如HTML和CSS)要花费更多时间。
  • 原生UI组件:虽然UI组件是React Native的最大优势之一,但目前只有少数几种现成的可用。
  • 本地代码:在某些情况下,开发者可能需要在移动应用中编写本地或平台特定的代码,特别是如需访问设备硬件(如相机或GPS),会破坏跨平台开发的目的,对小型团队来说React Native的作用不大。
  • 性能:虽然与大多数其他跨平台开发框架相比,React Native在性能方面表现优异,但比起使用特定于平台的工具和语言的本地应用进行开发来说仍有不足。

React Native 开发工具

  • Atom
    地址:https://atom.io/
  • Nuclide
    地址:https://nuclide.io/
  • Visual Studio Code
    地址:https://code.visualstudio.com/
  • React Native Tools
    地址:
    https://marketplace.visualstudio.com/items?itemName=vsmobile.vscode-react-native

React Native 开发组件

  • Redux
    地址:https://redux.js.org/
  • Expo
    地址:https://expo.io/
  • Ignite
    地址:https://infinite.red/ignite
  • Flow
    地址:https://flow.org/
  • ESLint
    地址:https://eslint.org/
  • ReduxSauce
    地址:
    https://github.com/infinitered/reduxsauce

React Native UI组件

  • Snowflake
    地址:
    https://github.com/bartonhammond/snowflake
  • NativeBase
    地址:https://nativebase.io/

React Native 测试工具

  • Enzyme
    地址:
    https://github.com/airbnb/enzyme
  • Reactotron
    地址:https://infinite.red/reactotron
  • Instabug
    地址:
    https://instabug.com/?src=InstabugBlog&mdm=internal&ref=cross_platform_development&term=instabug

Xamarin

Xamarin是一个跨平台的移动应用开发框架,由微软基于Mono(一个免费的开源.NET框架),使用C#创建本地应用。

Xamarin 优点

Xamarin跨平台移动应用开发具有多个优势,包括:

  • 可重用代码:开发应用并从单个代码库将其导出到多个平台上。
  • 应用商店:可以在各个平台的应用商店中发布应用。
  • 完整的开发堆栈:许多开发者认为Xamarin是最完整的跨平台移动应用开发框架。拥有自己的专用堆栈,C#作为编程语言;Visual Studio作为IDE,与Xamarin完全集成;.NET作为开发平台;Xamarin测试云进行测试;以及Xamarin.Insights用于分析。
  • 性能:Xamarin在性能方面也几乎与本地应用相同。 Xamarin比混合应用更快,因为混合应用必须在特定于平台的Web组件中运行代码。
  • 本地UI组件:使用Xamarin Native UI组件创建视图,这些组件通过Xamarin.Forms编译为特定于平台的UI组件,Xamarin.Forms包含面向.NET开发者的完整跨平台UI工具包,或可以通过Native UI开发。
  • 插件和API:Xamarin提供了一组允许访问硬件功能的插件和API。它还支持通过链接本地库进行自定义。 测试:通过在物理设备上安装Xamarin.Forms Live Player应用,开发者可以使用实时预览立即测试和调试应用,并可以实时同步应用与设备。
  • 可靠性:Xamarin于2016年被微软收购,截至目前,已在120多个国家/地区拥有超过140万名开发者。所以它绝对可靠且拥有良好的维护。
  • Xamarin大学:Xamarin提供由Xamarin专家指导的实时、互动的移动开发培训,涵盖10个方面的80多个课程,让开发者可以轻松地学习。
  • 免费:开源。

Xamarin 缺点

虽然Xamarin可以应用许多场景,但它也是有一些缺点的:

  • 应用大小:通常已知Xamarin应用大小比本地应用更大,因此在内存管理方面不是很理想。
  • 更新延迟:Xamarin的更新时间有时会比平台的更新更慢,无论是新功能的迭代还是其他,因此可能会导致应用出现一些问题。
  • 本地代码:当使用Xamarin.iOS或Xamarin.Android开发具有原生外观的移动应用时,将需要一些本地语言的基本知识,如Objective-C、Swift和Java。
  • 图形:虽然Xamarin使用单个代码库为多个平台构建应用,但它主要在平台之间共享代码逻辑,而UI组件又是特定于平台的。这使得Xamarin并不适合严重依赖图形的应用,比如手机游戏。

Xamarin开发工具

  • Visual Studio
    地址:
    https://visualstudio.microsoft.com/vs/mac/
  • XCode
    地址:
    https://developer.apple.com/xcode/

Xamarin 开发组件

  • NuGet
    地址:https://www.nuget.org/
  • Xamarin Inspector
    地址:
    https://docs.microsoft.com/zh-cn/xamarin/tools/inspector/install?tabs=windows
  • Prism
    地址:
    https://github.com/PrismLibrary/Prism
  • MFractor
    地址:https://www.mfractor.com/
  • Resharper
    地址:
    https://www.jetbrains.com/resharper/

Xamarin 测试工具

  • NUnit
    地址:http://nunit.org/
  • xUnit.net
    地址:https://xunit.github.io/
  • Visual Studio Unit Testing Framework
    地址:
    https://docs.microsoft.com/zh-cn/visualstudio/test/writing-unit-tests-for-the-dotnet-framework-with-the-microsoft-unit-test-framework-for-managed-code?view=vs-2015
  • Instabug
    地址:
    https://instabug.com/?src=InstabugBlog&mdm=internal&ref=cross_platform_development&term=instabug

Apache Cordova

Apache Cordova是一个跨平台的移动应用开发框架,用于使用包括HTML,CSS和JavaScript在内的Web技术,构建混合移动应用。

Apache Cordova 优点

使用Apache Cordova进行跨平台移动应用开发的一些优势包括:

  • 可重用代码:可以开发应用并从单个代码库将其导出到多个平台上。
  • 应用商店:可以在各个平台的应用商店中发布应用。
  • 多平台支持:Apache Cordova支持大多数开发者所使用的移动平台和操作系统,包括Android,iOS,Windows 8.1,iPhone 8.1和10,OS X,几乎可以覆盖所有移动用户。
  • 大量插件:Cordova提供各种插件。
  • 所用技术:Cordova不是一种编程语言,因此开发者可以使用已知的Web技术(如HTML,CSS和JavaScript)进行应用开发。还可以使用自身熟悉的工具,包括所使用的编辑器。
  • 免费:开源。

Apache Cordova 缺点

和任何跨平台移动应用开发工具一样,Cordova也缺点,包括:

  • 性能:使用Apache Cordova创建的移动应用,会因性能问题而受到影响,因为它是一种混合的跨平台移动应用开发工具。
  • 开发工具:由于Apache Cordova使用HTML,CSS和JavaScript等Web技术,因此用于Apache Cordova的大多数开发工具都针对Web开发进行了优化,而非移动应用开发。
  • 测试:在Apache Cordova中调试代码会比较繁琐,虽然可以使用开发工具修复任何代码上的bug,但需要使用特定于平台的工具来修复特定平台中发生的问题。
  • 技术:即便开发者可能熟练掌握了HTML,CSS和JavaScript等网络技术,但仍需要具备Web和移动应用的经验才能创建Cordova移动应用。
  • 支持的平台:Cordova多年来已经弃用了许多支持的平台,包括BlackBerry,Firefox OS,Symbian,Ubuntu Touch,webOS,Windows Phone 8.1和Windows Phone 10.虽然Cordova可能很难弃用iOS和Android,但仍然无法保证它继续支持任何其他当前所有平台。
  • 更新延迟:Cordova的更新时间有时会比平台的更新更慢,无论是新功能的迭代还是其他,因此可能会导致应用出现一些问题。
  • 插件:虽然Cordova提供了比其他任何跨平台开发工具中都多的插件,但它仍然无法与本机移动应用开发工具相比。

Apache Cordova 框架

  • Adobe PhoneGap
    地址:https://phonegap.com/
  • Monaca
    地址:https://monaca.io/
  • Onsen UI
    地址:https://onsen.io/
  • Cocoon
    地址:https://cocoon.io/
  • Framework7
    地址:http://framework7.io/
  • Evothings Studio
    地址:https://evothings.com/
  • Mobiscroll
    地址:https://mobiscroll.com/

Apache Cordova IDES

  • Visual Studio
    地址:
    https://visualstudio.microsoft.com/zh-hans/vs/features/cordova/
  • Cordova Tools Visual Studio Extensions
    地址:
    https://marketplace.visualstudio.com/items?itemName=vsmobile.cordova-tools
  • App Builder
    地址:
    https://www.davidesperalta.com/appbuilder
  • NSB/AppStudio
    地址:https://www.nsbasic.com/

Apache Cordova CLIS

  • Cordova CLI
    地址:
    https://github.com/apache/cordova-cli
  • Node.js
    地址:https://nodejs.org/en/
  • NPM
    地址:
    https://www.npmjs.com/package/cordova
  • Cordova Plugman
    地址:
    https://github.com/apache/cordova-plugman
  • Cordova Coho
    地址:
    https://github.com/apache/cordova-coho

Apache Cordova 类库

  • Apache Cordova JS
    地址:
    https://github.com/apache/cordova-js
  • Apache Cordova Lib
    地址:
    https://github.com/apache/cordova-lib
  • Apache Cordova Common
    地址:
    https://github.com/apache/cordova-common
  • Apache Cordova Create
    地址:
    https://github.com/apache/cordova-create
  • Apache Cordova Fetch
    地址:
    https://github.com/apache/cordova-fetch
  • Apache Cordova Serve
    地址:
    https://github.com/apache/cordova-serve

Apache Cordova 测试工具

  • Apache Cordova Plugin Test Framework
    地址:
    https://github.com/apache/cordova-plugin-test-framework
  • Apache Cordova Paramedic
    地址:
    https://github.com/apache/cordova-paramedic
  • Apache Cordova Mobile Spec Suite
    地址:
    https://github.com/apache/cordova-mobile-spec
  • Instabug
    地址:
    https://instabug.com/?src=InstabugBlog&mdm=internal&ref=cross_platform_development&term=instabug

总结

跨平台开发工具在开发周期中可以为开发者节省大量的时间,并可以使用最少的资源在不同的平台上发布应用,最大程度的去覆盖用户。但即便如此,它也无法替代本地开发应用的替代品,鱼和熊掌不可得兼,需要根据自身实际情况与场景去衡量利弊。

如何确定最适合的跨平台开发工具呢?最好的方法就是每个工具都去尝试一遍,如果时间有限,那么对一些顶级跨平台开发工具进行研究就足够了,比如本文例举的这些,希望对您有用。

干货分享丨研发代码质量管理技术最佳实践

如何高质量快速交付研发产品是每一位技术研发永恒追求的目标,如何在快速迭代发布下保障研发产品质量是每一位技术研发要共同思考的问题。

近日,在“安卓巴士全球开发者论坛·北京站”会议上,TalkingData SDK技术研发经理韩广利做了题为《研发代码质量管理最佳实践》的主题分享,将TalkingData SDK完整的质量保障体系的创建过程和最佳实践分享给所有开发者,希望能够对大家有帮助和借鉴。

TalkingData SDK技术研发经理 韩广利

以下是韩广利的分享精粹:

在演讲之初,韩广利首先分析了移动端平台发展趋势,包括以下三个方向:

  • 首先,双卡是移动端平台的主要趋势,今年9月发布的iPhone最新机型已经支持了双卡,这对于市场将起到很大的驱动作用。
  • 其次,由于人工智能的不断演进,两大平台也不断对其进行技术跟进,比如安卓平台的TensorFlow,以及iOS平台的CoreML。
  • 第三,用户隐私政策会越来越严格,不仅用户自身非常重视隐私,国家相关法规也日益完善,移动端平台的行为权限将逐步受到严格约束。

TalkingData基于相关政策为不同平台提供相应的适配和支持,也正因如此,就需要一个良好的代码质量管理体系去保证TalkingData SDK的质量和稳定性。

回顾TalkingData SDK整体架构的演进史,可以简单分为三个阶段:

  • 简单分层:只支持一条业务线;
  • 多服务:满足不同业务线逐渐增加的需求;
  • 微服务&模块化:满足不同开发者打包定制化的需求。

在功能叠加的过程中,需要对代码架构进行调整,那么此时应该思考两个问题:架构调整的原因什么?调整的目标是什么?

带着这两个问题,韩广利从四个部分进行了阐述。

代码分支管理

当代码分支不断增加,现有的人力和技术框架将无法支持功能的快速迭代。即便在某一个分支上解决了bug,但还需根据不同的场景将其添加到不同的分支上,分支的代码就会产生很大的差异,又需要投入更多的精力和时间去解决相关问题。

为此,TalkingData SDK进行了改造,将分支分为:对外发布交付分支、开发测试分支、以及个人创建分支。同时,也对原有的直接拉取分支的原因进行了一些反思:在架构设计之初,代码之间的耦合性较强,同时没有从业务或数据角度去进行独立设计,在打包的参数上没有进行动态配置。

为了改变现状,TalkingData制定了三个目标,一是改变模块之间的通讯方式;二是重新设计代码功能模块;三是约束代码之间的边界,尽量消除耦合性。

解决方案主要采用了微服务的思想——服务之间相互独立,随意调用或组合;对功能模块和数据模块进行了拆分;改变通讯方式做到解耦的效果,又将动态的配置参数分离出来,实现了支持多条业务线,并且可以满足定制化的需求。

在打包上进行了标签化的管理,同时配合标签检查脚本,达到定制化勾选和服务的打包功能。

韩广利表示,在架构重构时,需要进行一些取舍和选择,其核心思想是:架构在于目的而非框架,因为架构最终是要服务于业务的。他还提供了5大原则作为参考:

  • 独立于框架
  • 可测试性
  • 独立于UI
  • 独立于数据库
  • 独立于任何外部代理

而在选择架构时应从易于维护、易于测试、内聚以及最核心的解耦出发,要让模块之间互相独立。

SDK功能打包管理

TalkingData SDK提供不同业务线打包的定制化开发需求。在庞大的体量中,如何保证打包的功能正常、方便测试?为此,在设计目标当中加入了分层的考量,首先是用户输入信息:邮箱、业务线以及所需平台,然后是整个平台的业务处理、输出的用户申请功能包,最后通过邮件发送给申请的开发者。

逻辑流程如下图:

在打包管理中,比较常用的工具有 GitLab、Jenkins、Server。

代码review规则及流程

在代码review中设置人为检查和脚本检查两种机制。

在人为检查中,负责review的人员必须要参与最初的需求和设计的审核,不仅要了解整个功能需求的细节,还需要对功能或测试负责,撰写review checklist,最后要交付review 模板,在出现问题时可以进行问题追踪。

在脚本检查中,需要进行编译和制定代码规范、静态代码检查,以及安全漏洞等方面的工作。

以上两种机制可以让代码review真正起到作用,而避免沦为形式化流程。

TalkingData SDK在代码review时有几种方式:

  • 1对1:改动较小的bug、需求和优化
  • 1对多:改动较大的bug、需求和优化

与其他公司选用技术主管或特定人员作为代码review人员不同的是,TalkingData SDK 的代码review主要由组内成员相互之间进行,这样对于个人的技术和框架理解会有所帮助。

代码review模板主要有三个部分:谁做的review?发现了什么问题?如何解决整个问题?好的代码review模板要做到问题可记录、问题可追踪。

代码质量管理的工具

在代码质量管理的流程中,TalkingData SDK在代码托管上使用了GitLab,在项目管理上使用了JIRA。之所以选择这两个工具是因为两者可以互相打通,方便后续在遇到问题时可以根据记录进行排查。

研发流程如下图:

其中,单元测试在研发中是非常重要的,开发者写完一个功能模块的主流程通常没有问题,可以做到自测;但是分支的一些处理流程,即便交给测试人员也很难测试出来。因此单元测试就显得尤为重要,它可以覆盖很多异常分支,所输入的条件在参数当中可以动态设置。

QA测试流程如下图:

在前期,会由研发和QA整理一些测试用例,分为高中低等不同的级别,研发在提测时会有测试通过率,以保证测试的效率。

另外,TalkingData SDK 在上线后也需要去做一些监测,比如交付质量、对不需要功能做删减、打包的完整性等等。

总体来说,即采用微服务的思想,尽量让功能模块化管理,利用工具管理流程,进行单元测试,同时上线前后都要设置一些检查策略,做到万无一失。

最后,韩广利表示,流程并非形式,需要真正地落地执行,长此以往,就会对效率有很大地提升。

iView 发布 3.1.0 版本,支持TypeScript

作者|Jonathan Saring

译者|无明

来源丨公众号「前端之巅」

TalkingData经授权转载

编辑|覃云

原文丨https://hackernoon.com/21-top-vue-js-ui-libraries-for-your-app-4556e5a9060e

最近,随着“星球大战”(指 GitHub 的 Star 数量大比拼)的爆发,Vue.js 在 GitHub 上的 Star 数超过了 React。虽然 NPM 的下载量仍然落后于 React,但 Vue.js 的受欢迎程度似乎在持续增长。

1、Vuetify

Star 数为 11K,提供了 80 多个 Vue.js 组件,这些组件是根据谷歌 Material Design 指南实现的。Vuetify 支持所有平台上的浏览器,包括 IE11 和 Safari 9+(使用 polyfill),并提供了 8 个 vue-cli 模板。

地址: https://github.com/vuetifyjs/vuetify

2、Quasar

Star 数超过 6K,是构建 Vue.js 响应式网站、PWA、混合移动应用和 Electron 应用的流行框架。Quasar 还支持诸如 HTML/CSS/JS 压缩、缓存清除、摇树优化(tree shaking)、源映射、代码分割和延迟加载、ES6 转码等功能。

地址:https://github.com/quasarframework/quasar

3、Element

Star 数将近 28K,是一款面向 Web 的 Vue.js 2.0 UI 工具包。它拥有一个强大的社区和 350 个贡献者,提供了丰富的可定制组件,以及完整的样式指南和更多的资源。 地址:https://github.com/ElemeFE/element

4、Vue Material

Star 数差不多 6K,是一个实了谷歌 Material Design 的简单库。该库还提供了一个 webpack 样板、用于 Nuxt.js 的 SSR 模板和一个单独的 HTML 文件(通过这个文件开始使用框架)。这里有一些入门的例子https://codesandbox.io/s/github/vuematerial/examples/tree/master/examples/quick-start。

地址: https://github.com/vuematerial/vue-material

5、Keen-UI

Star 数将近 3.5 K,一组 Vue 组件的集合,在设计上受到了谷歌 Material Design 的启发。Keen-UI 并不是一个 CSS 框架,它不包含网格系统、排版样式等。相反,它关注的是基于 Javascript 的交互式组件。

地址:https://github.com/JosephusPaye/Keen-UI

6、Buefy

Star 数 3K 左右,基于 Bulma(https://bulma.io)提供了一组轻量级的 UI 组件。Vue.js 和 Bulma 是这个库唯一的两个内部依赖。它的大小约为 60KB(压缩后的大小,并且包含了 Bulma)。你可以查看实时文档网站(https://buefy.github.io/#/documentation/start)并在 Codepen 上运行代码。

地址: https://github.com/buefy/buefy

7、Bootstrap Vue

Star 数超过 5K,为 Vue.js 提供了 Bootstrap 4 组件和网格系统的实现,并提供了自动 WAI-ARIA 可访问性标记。

地址: https://github.com/bootstrap-vue/bootstrap-vue

8、Muse-UI

Star 数超过 6K,是另一个 Vue 2.0 MD 库,提供了 40 多个 UI 组件和可定制主题。文档主要使用中文撰写,不过大多数组件是自解释的,文档只起到辅助作用。该项目在积极开发和维护当中。 地址:https://github.com/museui/muse-ui

9、AT-UI

Star 数接近 1.5 K,一个模块化的前端 UI 框架,用于开发基于 Vue.js 的 Web 界面,适用于桌面应用程序。它提供了 NPM+Webpack+Babel 的前端开发工作流和独立的 CSS 样式,值得一试。

地址: https://github.com/at-ui/at-ui

10、Vux

Star 数超过 13K,是一个流行的社区库,基于 WeUI 和 Vue 2.0。该库还支持 webpack+vue-loader+vux 的工作流。它的文档也是中文的。

地址: https://github.com/airyland/vux

11、iView

Star 数将近 16K,提供了数十种用 Vue.js 构建的 UI 组件和小部件,并采用了干净而优雅的设计。iView 被广泛采用,社区也在积极维护,并提供了 CLI 工具用于以可视化的方式创建项目。这个也值得一试。

地址: https://github.com/iview/iview

12、Uiv

Star 数“仅”550 左右,用于 Vue 2 的 Bootstrap 3 组件库。所有组件加起来差不多 20KB,唯一的外部依赖是 Vue 和 Bootstrap CSS,支持基于 Webpack 的工作流。 地址:https://github.com/wxsms/uiv

13、Vuikit

Star 数 1K 左右,一个用于网站界面的响应式的 Vue UI 库,设计风格干净而统一。该库作为由 Yarn 工作区管理的“monorepo”而构建,但图标和主题可作为单独的包发布。

地址: https://github.com/vuikit/vuikit

14、Onsen UI+Vue

基于流行的 Onsen-UI 框架,封装了核心 Web 组件并暴露了 Vue 风格的 API。Onsen UI 组件也被设计为能够主动对 prop 做出反应。

地址: https://onsen.io/v2/guide/vue/

15、Semantic UI+Vue

这个项目基本上是 Semantic-UI 框架与 Vue.js 的集成。该库仍在开发当中,提供了一个类似于 Semantic-UI 的 API 以及一组可定制的主题。

地址: https://semantic-ui-vue.github.io/

16、Fish-UI

Star 数“仅”为 500 左右,贡献者也只有 3 个,但 fish-ui 提供了一个基于 Vue 的 Web 工具包,其中包含整洁干净的组件。该库支持 ES2015+Webpack 工作流。它的文档不是很全,但它的设计不容忽视。

地址: https://github.com/myliang/fish-ui

17、Mint UI

Star 数超过 11K,为 Vue.js 提供 UI 元素,提供了用于构建移动应用程序的 CSS 和 JS 组件。当全部导入时,压缩后的代码只有月 30KB(JS+CSS),当然它也支持单个组件的导入。

地址: https://github.com/ElemeFE/mint-ui/

18、Framework7 Vue

这个集成提供了几乎所有的 Framework7 元素和组件,并集成了 Framework7 Router,按照 Vue 的方式来渲染页面。该库正处于积极的开发和维护当中。 地址:https://framework7.io/vue/

19、Cube UI

Star 数超过 3K,是用于 Vue.js 移动应用程序的 UI 组件库。所有组件都经过了单元测试,并且该库还支持按需进行后期编译和组件导入。这个库仍在积极开发中。

地址: https://github.com/didi/cube-ui

20、Vueblu

Star 数约 1.5K,是基于 Vue 2.0 和 Bulma 的 UI 组件库,用于构建中台和后台办公产品。它支持 ES2015 和 NPM+Webpack+Babel 工作流,并提供可自定义主题。

地址: https://github.com/chenz24/vue-blu

21、Ant Design Vue

Star 数约 1.5K,用于开发具有数十个 Ant Design 实现组件的企业级后端产品,并支持基于 Webpack 调试的构建解决方案(支持 ES6)。请注意,它的开发已经停止了一段时间。

地址: https://github.com/okoala/vue-antd

特别推荐

n3-components :

https://github.com/N3-components/N3-components

vuikit:

https://vuikit.js.org/

Kendu UI Vue

https://www.telerik.com/kendo-vue-ui

Office Fabric-Vue

https://github.com/aidewoode/office-ui-fabric-vue

vuestrap

http://kzima.github.io/vuestrap-base-components/#/

vueboot

http://morgul.github.io/vueboot/

framevuerk

http://framevuerk.com/

Vue WeUI

http://aidenzou.github.io/vue-weui/#!/

Vue-MDC

https://github.com/posva/vue-mdc

重磅发布预告

排名11位的iView是由TalkingData数据可视化团队开源的UI组件库,也是一个充满情怀的开源项目。 在过去的一年里,iView共迭代了27个版本,还在近期发布了针对微信小程序开发的UI组件库——《iView Weapp》。 7.28是iView的两周年生日,iView团队也将在这一天举办发布会,正式发布iView 3.0以及5款与iView相关的神秘产品。点击文末阅读原文,就有机会亲临发布会现场。

产品专栏 | 灵动分析2.0开创埋点新时代

2018年8月TalkingData正式发布了移动运营平台5.0私有化部署版本,同时也发布了其中的一款无代码埋点利器——灵动分析2.0。

从连接系统到看数据全流程迅速响应——

5 秒  内连接系统

10秒 内完成一个埋点事件

30秒 拉取配置单上报数据

实时  查看报表数据

在灵动分析2.0时代,TalkingData最大程度的简化操作,降低业务与研发的沟通成本、学习成本,提高运营效率,让业务人员能够聚焦于数据。运营人员既不用读懂复杂的SDK集成文档,也不需要向研发解释埋点的业务逻辑,系统能够自动识别可埋点的元素,且支持事件参数埋点,全流程可视化,开创了国内可视化事件参数埋点的先河。

灵动分析本次迭代带来了7大亮点:

1、扫码进入5秒内连接系统

从扫码到连接系统只需5秒钟快速响应,取代旧版摇一摇,解决多人同时摇动抢占连接系统资源的尴尬,解决摇动多次连接不上或响应慢的烦恼。

2、支持多种模式的移动应用一站式埋点  

无论是混合模式app、原生app还是H5,都支持在PC端完成一站式埋点。

3、3种埋点方式 满足业务小姐姐的分析灵感

支持当前元素、当前位置、同类元素3种埋点方式,业务小姐姐可以根据分析需求选择适合的埋点方式,且从埋点到看数据全流程快速响应:

※ 10秒 内完成一个埋点事件

※ 30秒 拉取配置单上报数据

※ 实时 查看报表数据。

4、灵活添加参数 轻轻一点即可指哪采哪

国内首家独创的可视化事件参数埋点,业内尚未有任何一家具备此能力并与之匹敌。

例如,应用界面上的商品价格、商品类型等特定数据,只需拖动鼠标,系统就会智能识别可圈选元素,轻轻一点即可采集:

  • 一方面满足前端业务人员“指哪采哪”的业务分析需求;
  • 另一方面可以让前端非常动态的处理需求变化,而无需开发人员介入。

解决了前后端沟通成本,而且全流程可视化,业务人员可随时完成对各种数据的监控和追踪需求。

5、易测试 数据追踪无遗漏

可视化的数据点测试。您只需在测试设备中轻点各项元素,即可在实时界面中查看到数据产生,从此让数据验证变得异常简单。

6、零代码 解放IT小哥哥的双手 

灵动分析真正做到“零开发、零代码、云配置”架构,颠覆了传统应用统计使用方式,彻底解放了研发人员,无需再为应付琐碎的数据跟踪需求而苦恼,真正把研发时间都用到做好产品上。

7、免更新 自动识别埋点元素

灵动分析可以免去应用更新的种种麻烦,自动识别埋点元素。业务人员只需圈圈点点界面元素来追加数据点,实时生效,无需应用升级


灵动分析+个别事件代码埋点组合出击

综上所述,如果灵动分析已经帮助您解决了80%的埋点需求,那么这里仍建议您采用灵动分析+个别事件代码埋点的方式组合出击,毕竟不是所有用户的交互行为都适用于灵动分析。例如,用户上滑屏幕时内容瀑布流的底部载入新的内容,这种交互用户可以一直进行下去,但没有一个明确的监测点位置,在可视化事件监测设置的界面上找不到这类交互,但这种情况用代码埋点就很容易解决。

因此,采用灵动+代码埋点结合的方式,既能快速满足日常基础数据的收集需求,又能针对个别事件进行多维的数据采集与挖掘,达到整体兼顾数据收集的效率、平衡开发资源、提升运营效率的目标。