Java 系列博客文章

Netty 知识点 思维导图

点击大图查看

read more

Linux、网络相关

未来已来:云原生 Cloud Native
前言

自 2013 年容器(虚拟)技术(Docker)成熟后,后端的架构方式进入快速迭代的阶段,出现了很多新兴概念:

微服务 k8s Serverless IaaS:基础设施服务,Infrastructure-as-a-service PaaS:平台服务,Platform-as-a-service SaaS:软件服务,Software-as-a-service Cloud Native: 云原生 Service Mesh

后端架构的变迁和云计算的发展密切相关,架构其实在不断地适应云计算,特别是云原生,被誉为未来架构,在 2019 年,云原生落地方案 Service Mesh 在国内外全面开花,我认为,未来已来。

接下来,我们将:

梳理后端架构演化史,回顾后端架构发展历程; 回顾云服务发展历程,探讨云原生概念; 梳理云原生实现方案 Service Mesh 的发展历程; 介绍 Service Mesh 的代表 Istio 的亮眼功能; 后端架构演化史 集中式架构

集中式架构又叫单体式架构,在Web2.0模式并未大规模兴起时十分流行。后来,基于Web应用的B/S(Browser/Server)架构逐渐取代了基于桌面应用的C/S(Client/Server)架构。B/S架构的后端系统大都采用集中式架构,它当时以优雅的分层设计,统一了服务器后端的开发领域。

集中式应用分为标准的3层架构模型:数据访问层M、服务层V和逻辑控制层C。每个层之间既可以共享领域模型对象,也可以进行更加细致的拆分。

其缺点是

编译时间过长; 回归测试周期过长; 开发效率降低等; 不利于更新技术框架 分布式系统架构

对于互联网应用规模的迅速增长,集中式架构并无法做到无限制的提升系统的吞吐量,而分布式系统架构在理论上为吞吐量的上升提供了无限扩展的可能。因此,用于搭建互联网应用的服务器也渐渐地放弃了昂贵的小型机,转而采用大量的廉价PC服务器。

容器技术新纪元 Docker

分布式架构的概念很早就出现,阻碍其落地的最大问题是容器技术不成熟,应用程序在云平台运行,仍然需要为不同的开发语言安装相应的运行时环境。虽然自动化运维工具可以降低环境搭建的复杂度,但仍然不能从根本上解决环境的问题。

Docker的出现成为了软件开发行业新的分水岭;容器技术的成熟,也标志技术新纪元的开启。Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。就像当年智能手机的出现改变了整个手机行业的游戏规则一样,Docker也大有席卷整个软件行业,并且进而改变行业游戏规则的趋势。通过集装箱式的封装,开发和运维都以标准化的方式发布的应用,异构语言不再是桎梏团队的枷锁。

在 Docker 之后,微服务得以流行开来

微服务架构

微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储技术。

微服务优势

可扩展 可升级 易维护 故障和资源的隔离

微服务的问题

但是,世界上没有完美无缺的事物,微服务也是一样。著名软件大师,被认为是十大软件架构师之一的 Chris Richardson 曾一针见血地指出:“微服务应用是分布式系统,由此会带来固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间通讯机制。此外,他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。”

在微服务架构中,一般要处理以下几类问题:

服务治理:弹性伸缩,故障隔离 流量控制:路由,熔断,限速 应用观测:指标度量、链式追踪

解决方案 Spring Cloud(Netflix OSS)

这是一个典型的微服务架构图

Spring Cloud 体系提供了服务发现、负载均衡、失效转移、动态扩容、数据分片、调用链路监控等分布式系统的核心功能,一度成为微服务的最佳实践。

Spring Cloud 的问题

如果开始构建微服务的方法,肯定容易被 Netflix OSS/Java/Spring/SpringCloud 所吸引。但是要知道你不是Netflix,也不需要直接使用 AWS EC2,使得应用程序变得很复杂。如今使用 docker 和采用 memos/kubernetes 是明智之举,它们已经具备大量的分布式系统特性。在应用层进行分层,是因为 netflix 5年前面临的问题,而不得不这样做(可以说如果那时有了kubernetes,netflix OSS栈会大不相同)。

因此,建议谨慎选择,按需选择,避免给应用程序带来不必要的复杂度。

的确 SpringCloud 方案看起来很美好,但是它具有非常强的侵入性,应用代码中会包含大量的 SpringCloud 模块,而且对其他编程语言也不友好。

Kubernetes

Kubernetes 出现就是为了解决 SpringCloud 的问题,不侵入应用层,在容器层解决问题。

Kubernetes 起源

Kubernetes最初源于谷歌内部的Borg,提供了面向应用的容器集群部署和管理系统。

Kubernetes的目标旨在消除编排物理/虚拟计算,网络和存储基础设施的负担,并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。

Kubernetes 也提供稳定、兼容的基础(平台),用于构建定制化的 workflows 和更高级的自动化任务。 Kubernetes 具备完善的集群管理能力,包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。

Kubernetes 还提供完善的管理工具,涵盖开发、部署测试、运维监控等各个环节。

Service Mesh

Service Mesh 是对 Kubernetes 的增强,提供了更多的能力。

2018年9月1日,Bilgin Ibryam 在 InfoQ 发表了一篇文章 Microservices in a Post-Kubernetes Era,中文版见后 Kubernetes 时代的微服务(译文有些错误,仅供参考)。

文中作者的观点是:在后 Kubernetes 时代,服务网格(Service Mesh)技术已完全取代了使用软件库实现网络运维(例如 Hystrix 断路器)的方式。

如果说 Kubernetes 对 Spring Cloud 开了第一枪,那么 Service Mesh 就是 Spring Cloud 的终结者。

总结

最后我们用一个流程图来描述后端架构的发展历程

每个关键节点的大概时间表
架构/技术时间/年份集中式架构~分布式架构~Docker2013微服务2014Spring Cloud2014Kubernetes 成熟2017Service Mesh2017
可以看出,微服务生态这里,Spring Cloud 为代表的这条路已经后继无人了,未来属于 Service Mesh 。
Service Mesh 经过2年的发展,目前 Service Mesh 已经足够成熟,已经有生产落地的案例,我们接下来就看看 Service Mesh,在此之前,我们要先理解一个概念,云原生。

云原生 Cloud Native

如何理解“云原生”?之所以将这个话题放在前面,是因为,这是对云原生概念的最基本的理解,而这会直接影响到后续的所有认知。

注意:以下云原生的内容将全部引用敖小剑的 畅谈云原生(上):云原生应用应该是什么样子? 这篇文章,图画得太好了。

云原生的定义一直在发展,每个人对云原生的理解都可能不同,就如莎士比亚所说:一千个人眼中有一千个哈姆雷特。

2018 年 CNCF (Cloud Native Computing Foundation)更新了云原生的定义。


这是新定义中描述的代表技术,其中容器和微服务两项在不同时期的不同定义中都有出现,而服务网格这个在 2017 年才开始被社区接纳的新热点技术被非常醒目的列出来,和微服务并列,而不是我们通常认为的服务网格只是微服务在实施时的一种新的方式。

那我们该如何理解云原生呢?我们尝试一下,将 Cloud Native 这个词汇拆开来理解,先看看什么是 Cloud。

什么是云 Cloud

快速回顾一下云计算的历史,来帮助我们对云有个更感性的认识。

云计算的出现和虚拟化技术的发展和成熟密切相关,2000 年前后 x86 的虚拟机技术成熟后,云计算逐渐发展起来。

基于虚拟机技术,陆续出现了 IaaS/PaaS/FaaS 等形态,以及他们的开源版本。

2013 年 docker 出现,容器技术成熟,然后围绕容器编排一场大战,最后在 2017 年底,kubernetes 胜出。2015 年 CNCF 成立,并在近年形成了 cloud native 生态。

在这个过程中,云的形态一直变化,可以看到:供应商提供的功能越来越多,而客户或者说应用需要自己管理的功能越来越少。


架构也在一直适应云计算的变化

什么是原生 Native

在回顾完云计算的历史之后,我们对 Cloud 有更深的认识,接着继续看一下:什么是 Native?
字典的解释是:与生俱来的。
那 Cloud 和 native 和在一起,又该如何理解?

这里我们抛出一个我们自己的理解:云原生代表着原生为云设计。详细的解释是:应用原生被设计为在云上以最佳方式运行,充分发挥云的优势。

这个理解有点空泛,但是考虑到云原生的定义和特征在这些年间不停的变化,以及完全可以预料到的在未来的必然变化,我觉得,对云原生的理解似乎也只能回到云原生的出发点,而不是如何具体实现。

Cloud Native 是道,Service Mesh 是术

那在这么一个云原生理解的背景下,我再来介绍一下我对云原生应用的设想,也就是我觉得云原生应用应该是什么样子。

在云原生之前,底层平台负责向上提供基本运行资源。而应用需要满足业务需求和非业务需求,为了更好的代码复用,通用型好的非业务需求的实现往往会以类库和开发框架的方式提供,另外在 SOA/ 微服务时代部分功能会以后端服务的方式存在,这样在应用中就被简化为对其客户端的调用代码。

然后应用将这些功能,连同自身的业务实现代码,一起打包。

而云的出现,可以在提供各种资源之外,还提供各种能力,从而帮助应用,使得应用可以专注于业务需求的实现。
非业务需求相关的功能都被移到云,或者说基础设施中去了,以及下沉到基础设施的中间件。

以服务间通讯为例:需要实现上面列举的各种功能。

SDK 的思路:在应用层添加一个胖客户端,在这个客户端中实现各种功能。

Service Mesh 的思路,体现在将 SDK 客户端的功能剥离出来,放到 Sidecar 中。就是把更多的事情下沉,下沉到基础设施中。

在用户看来,应用长这样:

云原生是我们的目标,Service Mesh 交出了自己的答卷,接下来我们可以回到 Service Mesh 这里了。

Service Mesh

其中文译名是服务网格,这个词最早使用由开发Linkerd的Buoyant公司提出,并在内部使用。

定义

服务网格的基本构成

纷争 2017

2017 年年底,当非侵入式的 Service Mesh 技术终于从萌芽到走向了成熟,当 Istio/Conduit 横空出世,人们才惊觉:微服务并非只有侵入式一种玩法,更不是 Spring Cloud 的独角戏!

解读 2017 之 Service Mesh:群雄逐鹿烽烟起

文章总结一下:
创业公司 Buoyant 的产品 Linkerd 开局拿下一血;
Envoy 默默耕耘;
从 Google 和 IBM 联手推出 Istio,Linkerd 急转直下;
2017 年底 Buoyant 推出 Conduit 背水一战;
Nginmesh 与 Kong 低调参与;

百家争鸣 2018

2018 年,Service Mesh 又多了哪些内容呢?在 2018 年,Service Mesh 在国内大热,有多家公司推出自己的 Service Mesh 产品和方案,Service Mesh 更加热闹了。
详细见这篇文章 下一代微服务!Service Mesh 2018 年度总结

文章总结一下:
Service Mesh 在国内大热,有多家公司加入战场;
Istio 发布1.0,成为最受欢迎的 Service Mesh 项目,获得多方支持;
Envoy 继续稳扎稳打,Envoy 被 Istio 直接采用为数据平面,有望成为数据平面标准;
Linkerd1.x 陷入困境,Conduit 小步快跑,但响应平平,Buoyant 公司决定合并产品线,Linkerd1.x + Conduit = Linkerd2.0;
更多的公司参与 Service Mesh,国外有 Nginx、Consul、Kong、AWS等,国内有蚂蚁金服、新浪微博、华为,阿里 Dubbo,腾讯等;

持续发展 2019

2019 将会听到更多 Service Mesh 的声音,请关注Service Mesh 中文社区

Istio

前文讲到 Istio 是当前最受欢迎的 Service Mesh 框架,一句话定义 Istio:一个用来连接、管理和保护微服务的开放平台。
它能给我们的微服务提供哪些功能呢?

连接 动态路由 超时重试 熔断 故障注入

详细见官网介绍

保护

安全问题一开始就要做好,在 Istio 实现安全通讯是非常方便的。

Istio 支持双向 TLS 加密

见官方文档

控制

速率限制
黑白名单

见官方文档

观测 指标度量:每秒请求数,Prometheus 与 Grafana
使用 Grafana 观测流量情况

分布式追踪:Jaeger 或 Zipkin
快速观测调用链路

日志:非应用日志

网格可视化
快速理清服务的关系

总结

虚拟化技术推动这云计算技术的变革,顺带也影响了后端架构的演进,目前我们身处云时代,将会有更多的元原生应用出现,Istio 作为其中的佼佼者,值得你投入一份精力了解一下。

学习资料/指引

Service Mesh 中文社区 上面提供了丰富的学习资料。

搭建 Kubernetes 集群会比较麻烦,推荐几种方式。主要原因是很多镜像需要翻墙才能下载。

Docker Desktop 自带的 Kubernetes 集群 使用 Rancher2.0 搭建 Kubernetes 集群 在 Google Cloud 上直接开集群,可以领 300 美金的体验金,需要翻墙

不推荐 MiniKube,翻墙和代理问题非常难搞。
再附上 Docker 设置代理的方式

在线体验 Istio

参考资料

kubernetes-handbook

istio-handbook

微服务学习笔记

畅谈云原生(上):云原生应用应该是什么样子?

Service Mesh:下一代微服务?

从架构到组件,深挖istio如何连接、管理和保护微服务2.0?

原文链接
作者: 天如

read more

html/css/js/各种前端框架/工具

小程序多端框架全面测评:chameleon、Taro、uni-app、mpvue、WePY
小程序多端框架全面测评:chameleon、Taro、uni-app、mpvue、WePY

最近前端届多端框架频出,相信很多有代码多端运行需求的开发者都会产生一些疑惑:这些框架都有什么优缺点?到底应该用哪个?

作为 Taro 开发团队一员,笔者想在本文尽量站在一个客观公正的角度去评价各个框架的选型和优劣。但宥于利益相关,本文的观点很可能是带有偏向性的,大家可以带着批判的眼光去看待,权当抛砖引玉。

那么,当我们在讨论多端框架时,我们在谈论什么:

多端

笔者以为,现在流行的多端框架可以大致分为三类:

1. 全包型

这类框架最大的特点就是从底层的渲染引擎、布局引擎,到中层的 DSL,再到上层的框架全部由自己开发,代表框架是 Qt 和 Flutter。这类框架优点非常明显:性能(的上限)高;各平台渲染结果一致。缺点也非常明显:需要完全重新学习 DSL(QML/Dart),以及难以适配中国特色的端:小程序。

这类框架是最原始也是最纯正的的多端开发框架,由于底层到上层每个环节都掌握在自己手里,也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大,渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。

2. Web 技术型

这类框架把 Web 技术(JavaScript,CSS)带到移动开发中,自研布局引擎处理 CSS,使用 JavaScript 写业务逻辑,使用流行的前端框架作为 DSL,各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex,这样做的优点有:

开发迅速 复用前端生态 易于学习上手,不管前端后端移动端,多多少少都会一点 JS、CSS

缺点有:

交互复杂时难以写出高性能的代码,这类框架的设计就必然导致 JS 和 Native 之间需要通信,类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。React Native 有一些声明式的组件可以避免这个问题,但声明式的写法很难满足复杂交互的需求。 由于没有渲染引擎,使用各端的原生组件渲染,相同代码渲染的一致性没有第一种高。

3. JavaScript 编译型

这类框架就是我们这篇文章的主角们:Taro、WePY 、uni-app 、 mpvue 、 chameleon,它们的原理也都大同小异:先以 JavaScript 作为基础选定一个 DSL 框架,以这个 DSL 框架为标准在各端分别编译为不同的代码,各端分别有一个运行时框架或兼容组件库保证代码正确运行。

这类框架最大优点和创造的最大原因就是小程序,因为第一第二种框架其实除了可以跨系统平台之外,也都能编译运行在浏览器中。(Qt 有 Qt for WebAssembly, Flutter 有 Hummingbird,React Native 有 react-native-web, Weex 原生支持)

另外一个优点是在移动端一般会编译到 React Native/Weex,所以它们也都拥有 Web 技术型框架的优点。这看起来很美好,但实际上 React Native/Weex 的缺点编译型框架也无法避免。除此之外,编译型框架的抽象也不是免费的:当 bug 出现时,问题的根源可能出在运行时、编译时、组件库以及三者依赖的库等等各个方面。在 Taro 开源的过程中,我们就遇到过 Babel 的 bug,React Native 的 bug,JavaScript 引擎的 bug,当然也少不了 Taro 本身的 bug。相信其它原理相同的框架也无法避免这一问题。

但这并不意味着这类为了小程序而设计的多端框架就都不堪大用。首先现在各巨头超级 App 的小程序百花齐放,框架会为了抹平小程序做了许多工作,这些工作在大部分情况下是不需要开发者关心的。其次是许多业务类型并不需要复杂的逻辑和交互,没那么容易触发到框架底层依赖的 bug。

那么当你的业务适合选择编译型框架时,在笔者看来首先要考虑的就是选择 DSL 的起点。因为有多端需求业务通常都希望能快速开发,一个能够快速适应团队开发节奏的 DSL 就至关重要。不管是 React 还是 Vue(或者类 Vue)都有它们的优缺点,大家可以根据团队技术栈和偏好自行选择。

如果不管什么 DSL 都能接受,那就可以进入下一个环节:

生态

以下内容均以各框架现在(2019 年 3 月 11 日)已发布稳定版为标准进行讨论。

1. 开发工具

就开发工具而言 uni-app 应该是一骑绝尘,它的文档内容最为翔实丰富,还自带了 IDE 图形化开发工具,鼠标点点点就能编译测试发布。

其它的框架都是使用 CLI 命令行工具,但值得注意的是 chameleon 有独立的语法检查工具,Taro 则单独写了 ESLint 规则和规则集。

在语法支持方面,mpvue、uni-app、Taro 、WePY 均支持 TypeScript,四者也都能通过 typing 实现编辑器自动补全。除了 API 补全之外,得益于 TypeScript 对于 JSX 的良好支持,Taro 也能对组件进行自动补全。

CSS 方面,所有框架均支持 SASS、LESS、Stylus,Taro 则多一个 CSS Modules 的支持。

所以这一轮比拼的结果应该是:

uni-app > Taro > chameleon > WePY、mpvue

2. 多端支持度

只从支持端的数量来看,Taro 和 uni-app 以六端略微领先(移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序),chameleon 少了头条小程序紧随其后。

但值得一提的是 chameleon 有一套自研多态协议,编写多端代码的体验会好许多,可以说是一个能戳到多端开发痛点的功能。uni-app 则有一套独立的条件编译语法,这套语法能同时作用于 js、样式和模板文件。Taro 可以在业务逻辑中根据环境变量使用条件编译,也可以直接使用条件编译文件(类似 React Native 的方式)。

在移动端方面,uni-app 基于 weex 定制了一套 nvue 方案 弥补 weex API 的不足;Taro则是暂时基于 expo 达到同样的效果;chameleon 在移动端则有一套 SDK 配合多端协议与原生语言通信。

H5 方面,chameleon 同样是由多态协议实现支持,uni-app 和 Taro 则是都在 H5 实现了一套兼容的组件库和 API。

mpvue 和 WePY 都提供了转换各端小程序的功能,但都没有 h5 和移动端的支持。

所以最后一轮对比的结果是:

chameleon > Taro、uni-app > mpvue > WePY

3. 组件库/工具库/demo

作为开源时间最长的框架,WePY 不管从 Demo,组件库数量 ,工具库来看都占有一定优势。

uni-app 则有自己的插件市场和 UI 库,如果算上收费的框架和插件比起 WePy 也是完全不遑多让的。

Taro 也有官方维护的跨端 UI 库 taro-ui ,另外在状态管理工具上也有非常丰富的选择(Redux、MobX、dva),但 demo 的数量不如前两个。但 Taro 有一个转换微信小程序代码为 Taro 代码的工具,可以弥补这一问题。

而 mpvue 没有官方维护的 UI 库,chameleon 第三方的 demo 和工具库也还基本没有。

所以这轮的排序是:

WePY > uni-app 、taro > mpvue > chameleon

4. 接入成本

接入成本有两个方面:

第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势,开源的组件和库(例如 wxparse、echart、zan-ui 等)多是基于原生微信小程序框架语法写成的。目前看来 uni-app 、Taro、mpvue 均有文档或 demo 在框架中直接使用原生小程序组件/库,WePY 由于运行机制的问题,很多情况需要小改一下目标库的源码,chameleon 则是提供了一个按步骤大改目标库源码的迁移方式。

第二是原有微信小程序项目部分接入框架重构。在这个方面 Taro 在京东购物小程序上进行了大胆的实践,具体可以查看文章《Taro 在京东购物小程序上的实践》。其它框架则没有提到相关内容。

而对于两种接入方式 Taro 都提供了 taro convert 功能,既可以将原有微信小程序项目转换为 Taro 多端代码,也可以将微信小程序生态的组件转换为 Taro 组件。

所以这轮的排序是:

Taro > mpvue 、 uni-app > WePY > chameleon

流行度

从 GitHub 的 star 来看,mpvue 、Taro、WePY 的差距非常小。从 NPM 和 CNPM 的 CLI 工具下载量来看,是 Taro(3k/week)> mpvue (2k/w) > WePY (1k/w)。但发布时间也刚好反过来。笔者估计三家的流行程度和案例都差不太多。

uni-app 则号称有上万案例,但不像其它框架一样有一些大厂应用案例。另外从开发者的数量来看也是 uni-app 领先,它拥有 20+ 个 QQ 交流群(最大人数 2000)。

所以从流行程度来看应该是:

uni-app > Taro、WePY、mpvue > chameleon

5. 开源建设

一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化,但依然是衡量一个框架/库生命力的非常重要的标准。

从第三方贡献者数量来看,Taro 在这一方面领先,并且 Taro 的一些核心包/功能(MobX、CSS Modules、alias)也是由第三方开发者贡献的。除此之外,腾讯开源的 omi 框架小程序部分也是基于 Taro 完成的。

WePY 在腾讯开源计划的加持下在这一方面也有不错的表现;mpvue 由于停滞开发了很久就比较落后了;可能是产品策略的原因,uni-app 在开源建设上并不热心,甚至有些部分代码都没有开源;chameleon 刚刚开源不久,但它的代码和测试用例都非常规范,以后或许会有不错的表现。

那么这一轮的对比结果是:

Taro > WePY > mpvue > chameleon > uni-app

最后补一个总的生态对比图表:

未来

从各框架已经公布的规划来看:

WePY 已经发布了 v2.0.alpha 版本,虽然没有公开的文档可以查阅到 2.0 版本有什么新功能/特性,但据其作者介绍,WePY 2.0 会放大招,是一个「对得起开发者」的版本。笔者也非常期待 2.0 正式发布后 WePY 的表现。

mpvue 已经发布了 2.0 的版本,主要是更新了其它端小程序的支持。但从代码提交, issue 的回复/解决率来看,mpvue 要想在未来有作为首先要打消社区对于 mpvue不管不顾不更新的质疑。

uni-app 已经在生态上建设得很好了,应该会在此基础之上继续稳步发展。如果 uni-app 能加强开源开放,再加强与大厂的合作,相信未来还能更上一层楼。

chameleon 的规划比较宏大,虽然是最后发的框架,但已经在规划或正在实现的功能有:

快应用和端拓展协议 通用组件库和垂直类组件库 面向研发的图形化开发工具 面向非研发的图形化页面搭建工具

如果 chameleon 把这些功能都做出来的话,再继续完善生态,争取更多第三方开发者,那么在未来 chameleon 将大有可为。

Taro 的未来也一样值得憧憬。Taro 即将要发布的 1.3 版本就会支持以下功能:

快应用支持 Taro Doctor,自动化检查项目配置和代码合法性 更多的 JSX 语法支持,1.3 之后限制生产力的语法只有 只能用 map 创造循环组件 一条 H5 打包体积大幅精简

同时 Taro 也正在对移动端进行大规模重构;开发图形化开发工具;开发组件/物料平台以及图形化页面搭建工具。

结语

那说了那么多,到底用哪个呢?

如果不介意尝鲜和学习 DSL 的话,完全可以尝试 WePY 2.0 和 chameleon ,一个是酝酿了很久的 2.0 全新升级,一个有专门针对多端开发的多态协议。

uni-app 和 Taro 相比起来就更像是「水桶型」框架,从工具、UI 库,开发体验、多端支持等各方面来看都没有明显的短板。而 mpvue 由于开发一度停滞,现在看来各个方面都不如在小程序端基于它的 uni-app 。

当然,Talk is cheap。如果对这个话题有更多兴趣的同学可以去 GitHub 另行研究,有空看代码,没空看提交。

原文:https://blog.csdn.net/zhichaosong/article/details/88980582

read more
MySQL的InnoDB的幻读问题

MySQL InnoDB事务的隔离级别有四级,默认是“可重复读”(REPEATABLE READ)。

未提交读(READ UNCOMMITTED)。另一个事务修改了数据,但尚未提交,而本事务中的SELECT会读到这些未被提交的数据(脏读)。 提交读(READ COMMITTED)。本事务读取到的是最新的数据(其他事务提交后的)。问题是,在同一个事务里,前后两次相同的SELECT会读到不同的结果(不重复读)。 可重复读(REPEATABLE READ)。在同一个事务里,SELECT的结果是事务开始时时间点的状态,因此,同样的SELECT操作读到的结果会是一致的。但是,会有幻读现象(稍后解释)。 串行化(SERIALIZABLE)。读操作会隐式获取共享锁,可以保证不同事务间的互斥。

四个级别逐渐增强,每个级别解决一个问题。

脏读,最容易理解。另一个事务修改了数据,但尚未提交,而本事务中的SELECT会读到这些未被提交的数据。 不重复读。解决了脏读后,会遇到,同一个事务执行过程中,另外一个事务提交了新数据,因此本事务先后两次读到的数据结果会不一致。 幻读。解决了不重复读,保证了同一个事务里,查询的结果都是事务开始时的状态(一致性)。但是,如果另一个事务同时提交了新数据,本事务再更新时,就会“惊奇的”发现了这些新数据,貌似之前读到的数据是“鬼影”一样的幻觉。

借鉴并改造了一个搞笑的比喻:

脏读。假如,中午去食堂打饭吃,看到一个座位被同学小Q占上了,就认为这个座位被占去了,就转身去找其他的座位。不料,这个同学小Q起身走了。事实:该同学小Q只是临时坐了一小下,并未“提交”。 不重复读。假如,中午去食堂打饭吃,看到一个座位是空的,便屁颠屁颠的去打饭,回来后却发现这个座位却被同学小Q占去了。 幻读。假如,中午去食堂打饭吃,看到一个座位是空的,便屁颠屁颠的去打饭,回来后,发现这些座位都还是空的(重复读),窃喜。走到跟前刚准备坐下时,却惊现一个恐龙妹,严重影响食欲。仿佛之前看到的空座位是“幻影”一样。

一些文章写到InnoDB的可重复读避免了“幻读”(phantom read),这个说法并不准确。

做个试验:(以下所有试验要注意存储引擎和隔离级别)

mysql> show create table t_bitfly\G;
CREATE TABLE t_bitfly (
id bigint(20) NOT NULL default '0',
value varchar(32) default NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=gbk

mysql> select @@global.tx_isolation, @@tx_isolation;
+-----------------------+-----------------+
| @@global.tx_isolation | @@tx_isolation  |
+-----------------------+-----------------+
| REPEATABLE-READ       | REPEATABLE-READ |
+-----------------------+-----------------+

试验一:

t Session A                                   Session B

START TRANSACTION;            START TRANSACTION; SELECT * FROM t_bitfly; empty set INSERT INTO t_bitfly VALUES (1, 'a'); SELECT * FROM t_bitfly; empty set COMMIT; SELECT * FROM t_bitfly; empty set INSERT INTO t_bitfly VALUES (1, 'a'); ERROR 1062 (23000): Duplicate entry '1' for key 1

v (shit, 刚刚明明告诉我没有这条记录的)

如此就出现了幻读,以为表里没有数据,其实数据已经存在了,傻乎乎的提交后,才发现数据冲突了。

试验二:

t Session A                                     Session B

START TRANSACTION;              START TRANSACTION; SELECT * FROM t_bitfly; +------+-------+ id value +------+-------+ 1 a +------+-------+ INSERT INTO t_bitfly VALUES (2, 'b'); SELECT * FROM t_bitfly; +------+-------+ id value +------+-------+ 1 a +------+-------+ COMMIT; SELECT * FROM t_bitfly; +------+-------+ id value +------+-------+ 1 a +------+-------+ UPDATE t_bitfly SET value='z'; Rows matched: 2  Changed: 2  Warnings: 0 (怎么多出来一行) SELECT * FROM t_bitfly; +------+-------+ id value +------+-------+ 1 z 2 z +------+-------+

|
v

本事务中第一次读取出一行,做了一次更新后,另一个事务里提交的数据就出现了。也可以看做是一种幻读。

那么,InnoDB指出的可以避免幻读是怎么回事呢?

http://dev.mysql.com/doc/refman/5.0/en/innodb-record-level-locks.html

By default, InnoDB operates in REPEATABLE READ transaction isolation level and with the innodb_locks_unsafe_for_binlog system variable disabled. In this case, InnoDB uses next-key locks for searches and index scans, which prevents phantom rows (see Section 13.6.8.5, “Avoiding the Phantom Problem Using Next-Key Locking”).

准备的理解是,当隔离级别是可重复读,且禁用innodb_locks_unsafe_for_binlog的情况下,在搜索和扫描index的时候使用的next-key locks可以避免幻读。

关键点在于,是InnoDB默认对一个普通的查询也会加next-key locks,还是说需要应用自己来加锁呢?如果单看这一句,可能会以为InnoDB对普通的查询也加了锁,如果是,那和序列化(SERIALIZABLE)的区别又在哪里呢?

MySQL manual里还有一段:

13.2.8.5. Avoiding the Phantom Problem Using Next-Key Locking (http://dev.mysql.com/doc/refman/5.0/en/innodb-next-key-locking.html)

To prevent phantoms, InnoDB uses an algorithm called next-key locking that combines index-row locking with gap locking.

You can use next-key locking to implement a uniqueness check in your application: If you read your data in share mode and do not see a duplicate for a row you are going to insert, then you can safely insert your row and know that the next-key lock set on the successor of your row during the read prevents anyone meanwhile inserting a duplicate for your row. Thus, the next-key locking enables you to “<span style="padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;">lock</span>” the nonexistence of something in your table.

我的理解是说,InnoDB提供了next-key locks,但需要应用程序自己去加锁。manual里提供一个例子:

SELECT * FROM child WHERE id > 100 FOR UPDATE;

这样,InnoDB会给id大于100的行(假如child表里有一行id为102),以及100-102,102+的gap都加上锁。

可以使用show innodb status来查看是否给表加上了锁。

再看一个实验,要注意,表t_bitfly里的id为主键字段。实验三:

t Session A                                       Session B

START TRANSACTION;                START TRANSACTION; SELECT * FROM t_bitfly WHERE id<=1 FOR UPDATE; +------+-------+ id value +------+-------+ 1 a +------+-------+ INSERT INTO t_bitfly VALUES (2, 'b'); Query OK, 1 row affected SELECT * FROM t_bitfly; +------+-------+ id value +------+-------+ 1 a +------+-------+ INSERT INTO t_bitfly VALUES (0, '0'); (waiting for lock ... then timeout) ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction SELECT * FROM t_bitfly; +------+-------+ id value +------+-------+ 1 a +------+-------+ COMMIT; SELECT * FROM t_bitfly; +------+-------+ id value +------+-------+ 1 a +------+-------+

v

可以看到,用id<=1加的锁,只锁住了id<=1的范围,可以成功添加id为2的记录,添加id为0的记录时就会等待锁的释放。

MySQL manual里对可重复读里的锁的详细解释:

http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html#isolevel_repeatable-read

For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE),UPDATE, and DELETE statements, locking depends on whether the statement uses a unique index with a unique search condition, or a range-type search condition. For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it. For other search conditions, InnoDB locks the index range scanned, using gap locks or next-key (gap plus index-record) locks to block insertions by other sessions into the gaps covered by the range.

一致性读和提交读,先看实验,实验四:

t Session A                                                    Session B

START TRANSACTION;                             START TRANSACTION; SELECT * FROM t_bitfly; +----+-------+ id value +----+-------+ 1 a +----+-------+ INSERT INTO t_bitfly VALUES (2, 'b'); COMMIT; SELECT * FROM t_bitfly; +----+-------+ id value +----+-------+ 1 a +----+-------+ SELECT * FROM t_bitfly LOCK IN SHARE MODE; +----+-------+ id value +----+-------+ 1 a 2 b +----+-------+ SELECT * FROM t_bitfly FOR UPDATE; +----+-------+ id value +----+-------+ 1 a 2 b +----+-------+ SELECT * FROM t_bitfly; +----+-------+ id value +----+-------+ 1 a +----+-------+

v

如果使用普通的读,会得到一致性的结果,如果使用了加锁的读,就会读到“最新的”“提交”读的结果。

本身,可重复读和提交读是矛盾的。在同一个事务里,如果保证了可重复读,就会看不到其他事务的提交,违背了提交读;如果保证了提交读,就会导致前后两次读到的结果不一致,违背了可重复读。

可以这么讲,InnoDB提供了这样的机制,在默认的可重复读的隔离级别里,可以使用加锁读去查询最新的数据。

http://dev.mysql.com/doc/refman/5.0/en/innodb-consistent-read.html

If you want to see the “freshest” state of the database, you should use either the READ COMMITTED isolation level or a locking read:
SELECT * FROM t_bitfly LOCK IN SHARE MODE;

结论:MySQL InnoDB的可重复读并不保证避免幻读,需要应用使用加锁读来保证。而这个加锁度使用到的机制就是next-key locks。

==================== 结尾 ====================

作者: bitfly. 转载请注明来源或包含本信息. 谢谢
链接: http://blog.bitfly.cn/post/mysql-innodb-phantom-read/

read more
APK反编译总结
1.准备环境

win7
android-sdk_r24.0.2-windows.zip
jdk7
android studio1.5
eclipse
charles

温馨提示:后面三个工具都需要jre|jdk环境,请首先安装jdk.

2.抓包过程

通过在PC端安装charles软件,android端设置网络代理,抓取网络数据包。

2.1、PC端:在pc端创建wifi热点共享给外设->CMD命令行

netsh wlan set hostednetwork mode=allow ssid=abcd key=abcd1234

选择正在使用的网络连接,右键共享->勾选并选择刚刚创建的热点连接

netsh wlan start hostednetwork

charles:proxy setting 设置代理端口,若需https抓包请设置ssl选项,并且客户端安装charles证书

2.2、客户端:WLAN设置刚创建的“abcd”共享,并指定代理IP和端口号(自己ipconfig查看即可)

3.准备反编译工具

主要针对jvm的class文件和android虚拟机字节码smali,所需软件如下:

apktool_2.0.0rc4.zip ---- 可以得到apk里的资源和smali文件 dex2jar-2.0.zip ---- 获得class文件 jd-gui.exe ---- 反解class文件 signapk.rar ---- 修改smali或者资源文件,重新打包签名,***DEBUG*** 4.开始吧

这里以反编译土豆 app为例:

得到res和smali

java -jar apktool.jar d -d ..\..\youku\tudou\tudoushipin_61.apk -o ..\..\youku\tudou\tudoushipin_61

得到class

dex2jar.bat tudoushipin_61.apk

对上面的class使用jd-gui反编译,并导入eclipse

5.上演调试 && android studio

将smali文件导入到android studio

5.1、找到刚才apktool反解的目录找到AndroidManifest.xml,LAUNCHER对应的Activity标签上加入可被debug的配置android:debuggable="true",并保存。

5.2、假设我们现在把断点加载app的启动入口:
找到APK的入口Activity类(搜索关键字LAUNCHER你懂得),也就是:com.tudou.ui.activity.WelcomeActivity。

到了关键性的一步,找到这个Activity对应的smali文件;
定位到入口方法:onCreate;
在下面加入DEBUG代码,app启动时加入断点会停在这个位置;
说明一下:这段代码是smali的语法更多了解可以自行Google,OK。

a=0;// invoke-static {}, Landroid/os/Debug;->waitForDebugger()V

说明:根据你的需要可以把断点加到任意位置,前提是你要知道它在对应的smali文件的哪一行:方法是拿反编译后的Java文件和smali对应着去看,然后再找;后面的DEBUG也是这个思路(剧透)。

5.3、对修改后的apk重新打包

i.重新打包:

java -jar apktool.jar b -d ..\..\youku\tudou\tudoushipin_61 -o debug-tudou.apk

ii.重新签名:

java -jar signapk\signapk.jar signapk\testkey.x509.pem signapk\testkey.pk8 debug-tudou.apk debug-tudou.sign.apk

iii.一切可能都不是那么顺利):(

5.4、开启android studio-->基于知名的IntelliJ IDEA开发

1.导入之前反编译得到的smali文件到android studio,并在‘前面加debug代码’的地方加入断点。
2.找一部android手机(模拟器就算了,又慢又总是不兼容),安装刚才的签名后的apk,通过USB数据线接入PC。

5.5、有一些必要的说明

1.默认安装完android studio,例如:C:\dev\android\sdk
2.对于android Dalvik虚拟机的调试监控,DDMS已经被废弃了,新的是tools下的monitor工具,将其启动
3.在monitor中会看到devices中会出现小手机图标,端口号一般是8600

6.开始远程调试

1.android studio中菜单栏->RUN->Edit Configuration -> Remote(这根在eclipse中差不多)
指定host:localhost,端口:8600,module:smali所在的位置
启动app-->运行debug即可 -> 顺利的话光标会定位到你刚才的断点处。

2.观察Android Monitor窗口
观察Debugger tag,可以查看对象和变量的值

@hell 分享

read more

交流讨论专区,各种水~

Wiki
Javascript jQuery Fundamentals - jQuery 入门教程。 JavaScript库 代码解构 - 将JavaScript流行框架源代码条分缕析展现出来 深入理解Javascript系列 <Script>的defer和async的区别 Javascript面向对象基础 Backbone.js基础 JavaScript Madness: Keyboard Events Let's Make Frameworks 国内公司JS框架:Kissy - Taobao | Arale - Alipay | Tangram - Baidu JS1K, 1k Javascript contest JSON Home Page NB JS Wiki(CSS、PHP、jQuery、Linux) 理解并解决IE的内存泄漏方式 2 3 4 Understanding and Solving Internet Explorer Leak Patterns Javscript Bind函数 Javscript设计模式 JSON工具: JSONLint - The JSON Validator SimpleJSON - Python Stuff JSON Formatter (& Validator!) Tidy JSON - JSON Pretty Printer/Colorer - C#(.NET) Cerny.js - JSON Pretty Printing Demo jsonpretty(ruby) Vim Json: tidify a json in Vim JSON.vim - syntax VIM - How to format and syntax highlight JSON file Add JSON syntax highlighting in Vim on OS X JSONP: 使用 JSONP 实现跨域通信,第 1 部分: 结合 JSONP 和 jQuery 快速构建强大的 mashup 第 2 部分: 使用 JSONP、jQuery 和 Yahoo! 查询语言构建 mashup JSONP的起源 Mashups:Web 应用程序新成员 Javascript闭包: 闭包 (计算机科学) Javascript Closures 什么是闭包 Javascript Closures 中文 2 学习Javascript闭包(Closure) 作用域链 词法作用域 与 闭包(一) (二) Javascript工具: JSLint JavaScript Lint Fork of hallettj/jslint.vim Google Closure Compiler压缩优化规则初探 使用Google 的Closure Compiler来压缩javascript 在项目中使用Google Closure Compiler Mac下用Closure compiler JS 库浅析之 Google Closure Closure Compiler 高级模式及更多思考 Closure Compiler vs YUICompressor Minify JS QUnit @github JsBeautify:Online Javascript jsbeautifier github , vimscript js beautifier - plugin for Chrome NodeJS: nodeJS - 服务器端 JavaScript 编程 Node.js is genuinely exciting 在cygwin环境下编译node.js node char - 用 nodeJS 写的聊天室 Joyent Node | mattn.no.de HTML & CSS CSS Hacks & Expression XHTML Character Entity Reference HTML实体字符引用 精选15个国外CSS框架 Pure Css Speech Bubbles CSS栅格系统(Grid System): The 1Kb CSS Grid - 拖放各个阈值并直接下载自动生成的CSS。 Variable Grid System - 可直接修改各个阈值并预览效果。 Grid Designer YAML Builder - A tool for visual development of YAML based CSS layouts. 960 Grid System 960-Grid-System@github 网页的栅格系统设计 - 青云 我的栅格系统 - 明城 Five simple steps to designing grid systems 2 3 4 5 CSS疑难杂症: HasLayout和BFC(Block Formatting Contexts)的区别完整对比 Block Formatting Contexts的特性 hasLayout.net On having layout 中文版 Internet Explorer 6 and the Expanding Box Problem 万能清除浮动样式 CSS Border使用小分享 表格樣式集錦 复选框单选框与文字对齐问题的研究与解决 连续字符自动换行的解决方案 三谈Iframe自适应高度 | 再谈iframe自适应高度 跨浏览器的inline-block en display:inline-block的深入理解 HTML5 & CSS3 Dive Into HTML5 HTML5训练营 HTML5 WebSockets IE支持HTML5 感受HTML5&CSS3 用JavaScript玩转计算机图形学:(一)光线追踪入门 (二)基本光源 Canvas: Canvas (HTML元素) Canvas Tutorial Canvas 教程 en The canvas element HTML5 Canvas Canvas使用教程: 开题 基本语法 图形绘制 图片应用 Canvas Games: Unreal Soccer Canvascape Plasma demo using the HTML Canvas element Lodes Computer Graphics Tutorial CubeOut - 3D 俄罗斯方块 自行车越野 Box2DJS Canvas Cycles Agent 8 Ball - 台球 工具: CSS3 Generator CSS3 Gradient Generator CSS3 Button Maker CSS3 Please! - The Cross-Browser CSS3 Rule Generator Framework: mxGraph - the AJAX diagramming soluting Scalable Vector Graphics Web Browser using Flash HTML5 Canvas for Internet Explorer Library that provides support for SVG and VML with an SVG style interface DHTML: Draw Line, Ellipse, Oval, Circle, Polyline, Plygon, Triangle, with JavaScript 翻译Browser Drawing一篇:Canvas/SVG/VML Drawing Roundup Three.js Rapha?l - 非常棒的跨平台 JavaScript 图形库 | raphael@github | blog uupaa.js spin-off projects Demo: Alex Buga Livingroom burn-canvas-test - 画图 10 HTML5 Demos to Make You Forget About Flash cn deviantART Muro Biolab Disaster - Game 乒乓球游戏:左边用Flash,右边用HTML5 20 Things I Learned About Browsers and the Web Pure CSS Twitter 'Fail Whale' CSS3-Man A啦多梦告诉你浏览器对 CSS3 的支持程度 前端相关 World Wide Web Consortium The Web Standards Project W3Schools Online Web Tutorials HTTP 状态代码 网页错误代码详解 w3school - 在线教程 REST介绍 浏览器兼容解决方案 (AliceUI) | W3C 标准文档 (AliceUI) Microformats:Microformats | 什么是微格式及经典实例演示 | 微格式 - Wikipedia en | Microformats Cheat Sheat | 微格式全功略Hcard、 hCalendar、hReview、XFN 轻松掌握 | 微格式 Microformats ? hCard | 使用微格式来丰富网站语义:简介 | Getting Semantic With Microformats, Introduction Python 简明Python教程 Dive Into Python中文版 Dive Into Python3中文版 啄木鸟社区Wiki Python绝对简明手册 正则表达式 正则表达式30分钟入门教程 2 正则表达式工作室 | 揭开正则表达式的神秘面纱 | 正则表达式话题 | DEELX 正则引擎性能与特点 各种工具之正则表达式语法比较 2 Regular_Expression 入门 Lesson: Regular Expressions(Java) Regular expression operations(Python) 正则表达式 - 维基百科 RegExp - Mozilla 学习 Linux,101: 使用正则表达式搜索文本文件 构建用于正则表达式的抽象 Java API Regexp Syntax Summary JavaScript, Regex, and Unicode 《理解正则表达式(程序员第3期文章)》 利用有限自动机分析正则表达式 《Linux系统最佳实践工具:命令行技术》 我爱正则表达式 正则表达式论坛 正则表达式工具:Regexpal (online) 2 | RegExr | RegexBuddy | Expresso (free, open-source) | Match Tracer | HiFi Regex Tester | RegEx Builder 开发相关

MarkDown语法

HTML转义

OAuth

OAuth

OAuth核心

OAtuh for Web Application

Vim-oauth

webapi-vim

OAuth在线测试:服务端 | 客户端

国内开源镜像站:Sohu.com | 163.com

在线IDE:CodeRun | jsFiddle | JS Bin | 小可<Little Code />

优良的文本处理工具:SED & AWK

sed.sf.net | AWK @wikipedia 中文

Gawk for Windows | Sed for Windows

sed-非交互式文本编辑器(L.E.McMahon 著,中文翻译) En | awk-模式扫描与处理语言(Aho,Kernighan,Weinberger著,中文翻译)(第二版) En

详解注明的AWK oneliner:一:空行、行号和计算 | 二:文本替换 | 三:选择性输出特定行 | 四:定义字符串和数组

详解AWK oneliner原文:Famous Awk One-Liners Explained | Update on Famous Awk One-Liners Explained: String and Array Creation

sed和awk的简单使用 - 潘魏增

参考书籍:The AWK Programming Language | Effective awk Programming, Third Edition | sed & awk, Second Edition | sed and awk Pocket Reference, Second Edition

函数式编程:

@wikipedia 中文

对象-函数式编程简史 2

用函数式编程技术编写优美的 JavaScript

函数式编程 - 老赵

函数式编程 - czk wiki

函数式编程の道

哪种语言将统治多核时代 再看函数式语言特性

The Tao Of Programming ,2 ,《编程之道》 文言文版 by Livecn,2 白话文版 by 小赵

代码高亮:DlHightLight代码高亮组件 | Google Code Prettify

版本控制 版本控制系统(RCS)的选择与比较 拥抱Mercurial---选择分布式版本控制工具 几个分布式vcs比较 Comparison of revision control software 代码片段管理: gist@github notepad.cc Snipt.org Ubuntu Paste Pastebin Lodge It! SVN相关: Subversion 与版本控制 TortoiseSVN 中文帮助手册(v1.4.1) v1.6.8 Tigris.org - for Windows. Subversive中文站 Subclipse Subversive RabbitVCS - for Linux. Ubuntu下最好用的SVN客户端 SVN 命令行 Mercurial相关: Mercurial | Mercurial 使用教程 Hg Init: a Mercurial tutorial Mercurial: The Definitive Guide read 在Google Code上用 Mercurial 取代 Subversion 管理你的项目 乔尔谈软件终结篇:分布式版本控制系统的时代到来了 - 讲到了分布式版本控制的精髓:管理变更,而不是管理版本。 A Git User’s Guide to Mercurial Queues Mercurial托管服务:Mercurial hosting - bitbucket.org | KilnHg Git相关: Git - the Fast Version Control System. Stanford出品的Git Magic教程 最详细Git介绍:Pro Git (book , 中文版 ) Git官方帮助文档 简明教程:git 之五分钟教程 | 进一步学习 Git | 使用 Git 管理源代码 | 分布式版本控制工具Git简明笔记 | 译文:GIT日常命令20来条 Git开发管理之道 Git讨论:Why Git is Better than X | Git 改变了分布式 Web 开发规则 | 为什么说 Git 将取代 SVN 做软件版本控制? SVN+GIT=鱼与熊掌兼得 面向 Subversion 用户的 Git:一: 入门指南 | 面向 Subversion 用户的 Git,第 2 部分: 实施控制 Git的推广心得 | 你为神马不用git-flow呢? | 开始实践git-flow github | jekyll | codes | demos | GitHub Pages | Publishing a Blog with GitHub Pages and Jekyll 系统相关 用win+r启动程序和文档 Linux彻底定制指南(Linux From Scratch) 服务器和架构方面的一些文章 Linux Shell常用技巧(目录) Linux Shell高级技巧(目录) Ubuntu新手入门指引 | Ubuntu桌面入门指南 终端(Terminal):zsh | zsh.sf.net | 终极Shell——Zsh | 把 Mac 上的 bash 换成 zsh | zsh – 给你的Mac不同体验的Terminal! | oh-my-zsh@github 网络监控:Fiddler 2 | HttpWatch | Charles 远程控制: SSH技巧详解:SSH: More than secure shell SSH:SSH Filesystem | 在 Ubuntu 上使用 sshfs 映射远程 ssh 文件系统为本地磁盘 | MacFUSE | sshfs for Mac OS X SecureCRT:SecureCRT | SecureCRT 常用命令 PuTTY:PuTTY | PuTTY 中文版 | PuTTY: A Free Telnet/SSH Client | PuTTY 中文教程 | @google docs | | @wikipedia cURL:cURL and libcurl | docs | PHP: cURL - Manual | libcurl的使用总结(一) | libcurl的使用总结(二) rsync:rsync | zh@wikipedia | en@wikipedia | A Tutorial on Using | cwrsync - Rsync for Windows | 如何用 Rsync 来备份 Linux 文件 | AIX 上配置 rsync 简记 | 用 Rsync(cwRsync)备份 Dreamhost 到 Windows 上 | Rsync 与 OpenSSH 结合运用进行文件同步 Email相关: HTML Email Boilerplate - Email模板 如何發送內嵌圖片的 E-mail ( Inline Attachment ) 发送内嵌图片邮件的正确方法 使用 Commons-Email 在邮件内容中直接嵌入图片 内嵌图片或附档 HTML email inline styler CSS to inline styles converter 设计相关 图片、图标(Icons): 2011年50个最佳图标设计集合 FindIcons图标搜索引擎 Icon Archive PNG icons & Icons Picks Download DryIcons - Free Icons and Vector Graphics Icon Easy Tutorial9 | Photoshop Tutorials, Photography Tuts, and Resources 16 Sketchy Hand Drawn Icon Sets Gnome Icon Theme dutch icon? 开源图标库 PhotoShop:PhotoShop通道白解 | PhotoShop CS5序列号 字体: 什么是衬线体 文泉驿 - 开源字体。开彼源兮,斯流永继。 让代码更美:10大编程字体 Type is Beautiful - 字体排版 Google Font Directory ASCII Generator 假文填充:Lorem ipsum | 中文假文MoreText.js MoreText的Vim插件 | 亂數假文產生器 Chinese Lorem Ipsum 表格: 15个优秀的表格设计技巧 Creating a table with dynamically highlighted columns like Crazy Eggs pricing table 越减越妙:简单表格的再设计 15款提高表格操作的jQuery插件 资源: Dribble:著名设计师聚合网站 站酷:交流设计、分享快乐 全景:创意图片库 Designlol:全球设计精享 Designboom 配色方案:Color Schemer | kuler | Piknik Color Picker 80多个绝对漂亮的双屏壁纸 VIM 配置挑选Vim颜色(Color Scheme) VIM折叠简介 FuzzyFinder快速查找文件

转自:https://www.luxiaolei.com/wiki

read more
Solidity IDE Remix中文版
E

Remix是以太坊官方开源的Solidity在线集成开发环境,可以使用Solidity语言在网页内完成以太坊智能合约的在线开发、在线编译、在线测试、在线部署、在线调试与在线交互,非常适合Solidity智能合约的学习与原型快速开发。

Solidity IDE中文版Remix由汇智网提供,国内CDN加速,访问地址:http://remix.hubwiz.com

如果要快速掌握以太坊智能合约与DApp开发,推荐汇智网的以太坊开发系列教程

Solidity IDE Remix为左中右三栏布局,左面板为Remix文件管理器,中间为文件编辑器,
右侧为开发工具面板:

1、Solidity IDE Remix文件管理器

Remix左面板中的文件管理器,用来列出在浏览器本地存储中保存的文件,分为browser和config两个目录,
当你第一次访问Remix的时候,在browser目录下有两个预置的代码:ballot.sol合约以及对应的单元测试
文件ballot_test.sol,点击文件名就可以在中间的文件编辑器中查看并编辑代码:

Remix文件管理器顶部的工具栏提供创建新文件、上传本地文件、发布gist等快捷功能,你可以将鼠标移到
相应的图标处停顿,然后查看功能的浮动提示信息。

为了后续功能的学习,你可以点击左上角的+创建一个新的solidity合约文件,在弹出的对话框中,将
文件命名为hello.sol:

点击[ok]按钮后,你就可以看到在左面板的文件管理其中browser目录下出现了hello.sol文件名,
同时在中间区域的文件编辑器中自动打开了这个新创建的文件等待编辑,现在它还是空的,我们将在下面
编写简单的Solidity代码。

2、Solidity IDE Remix编辑器及终端

Solidity IDE Remix中间区域为上下布局,分别提供文件编辑功能和终端访问功能。

2.1 Remix文件编辑器

Solidity IDE Remix中间区域上方的文件编辑器支持同时打开多个文件,当前激活的文件,其文件名以粗体显示:

Remix文件编辑器顶部左右两侧的箭头,分别用来切换左右面板的显示与隐藏;左上角的+和-,
分别用来放大或缩小编辑器里的文本字体大小。

现在我们激活hello.sol文件,然后输入简单的合约代码:

pragma solidity ^0.5.1; contract Hello{ function echo(string memory text) public pure returns(string memory) { return text; } }

基本上这是最简单的以太坊合约了,它只有一个echo()方法,作用就是把输入的字符串
再原样返回。

2.2 Remix终端

Solidity IDE Remix中间区域下方为终端,可以输入JavaScript命令与Remix IDE或区块链节点交互:

Remix终端内置了web3.js 1.0.0、ether.js、swarmgy以及当前载入的Solidity编译器,因此你可以
在终端内使用熟悉的web3 API与当前连接的区块链节点交互。

Remix终端同时也内置了remix对象,可以利用它来脚本化地操作Solidity Remix IDE,例如载入指定
url的gist,或者执行当前显示的代码。将终端显示向上滚动到开始位置,就可以看到remix对象的
常用方法描述。

Remix终端的另一个作用是显示合约执行或静态分析的运行结果。例如,当你部署一个合约后或执行
一个合约方法后,就会在终端看到它的执行信息:

点击信息行右侧的下拉图标,就可以查看该信息的详情;点击[debug]按钮,就会打开右侧面板中的
调试页对合约进行单步或断点调试。

Remix终端顶部的工具栏提供了切换终端显示状态、清理终端输出等功能,显示待定交易的量,
选择监听交易的范围,也可以搜索历史交易。

3、Solidity IDE Remix功能面板

Solidity IDE Remix的右侧为功能面板,以选项页的方式提供编译、运行、静态分析、测试、
调试、设置和技术支持功能。

3.1 编译选项页

在编译选项页,你可以点击下拉框切换当前要使用的Solidity编译器版本:

然后点击[开始编译]按钮,就会编译Remix文件编辑器中当前选中的代码文件,比如我们的
hello.sol文件。编译完成后,如果没有编译错误,就可以看到合约名字Hello出现在编译
选项页的合约下拉框中:

可以点击[swarm]按钮将编译好的合约上传到Swarm网络,或者点击[详情]按钮查看编译
结果详情,也可以点击[ABI]或[字节码]按钮,分别将合约的ABI与字节码拷贝到系统剪切板
以便在其他程序中使用。

3.2 运行选项页

在运行选项页,可以部署编译好的合约,也可以执行已部署合约的方法:

节点环境选项提供三种选择:JS虚拟机、注入Web3对象或使用web3提供器。

JS虚拟机是一个JS版本的以太坊虚拟机实现,它运行在你的浏览器内,因此你不需要考虑
节点配置或者担心损失以太币,最适合学习和快速原型验证。 如果你的浏览器安装了Metamask插件,或者使用Mist之类的以太坊兼容浏览器,那么也
可以选择第二个环境:使用注入的Web3对象。 如果你有自己的节点,那么可以选择第三个选项使用web3提供器来让Remix连接
到你的节点上,不过如果要连接的节点是接入以太坊主网的,要注意每一次交易都是
有成本的!

如果之前有编译好的合约,在运行选项页就可以看到这个合约的名字,例如我们的Hello。
点击[部署]按钮就可以将这个合约部署到我们选定的节点环境了:

现在可以看到,已部署的合约区域,已经出现我们的合约了。点击这个合约实例,
可以看到我们为Hello合约定义的echo方法自动显示出来了:

在方法名后面的输入框里输入方法参数,例如"helloooooooooooooo",然后点击方法名,
就可以执行合约的方法了:

你看到,返回值的确和我们输入的参数是一样的,我们实现了预定目标!

3.3 其他选项页

Solidity Remix集成开发环境还有很多功能值得研究,这个工作留给你自己了。我们只对其他
的选项页做简单介绍:

分析选项页提供对Solidity合约代码的静态分析选项。 测试选项页提供单元测试能力,你可以生成一个测试文件,或者执行一组测试。 调试器选项页可以单步跟踪合约的执行、查看合约状态或局部变量等。 设置选项提供Solidity Remix IDE本身的一些参数调整能力,例如设置编辑器文本自动折行、
启用插件、设置gist访问令牌,或者切换Remix IDE的皮肤主题 —— 目前只有三个:浅色、深色和净色。

原文:Solidity IDE Remix中文版 - 汇智网

read more