如何对API进行负载测试与调优(2)

声明

本文由Donny译自 3scale.com 的 《How to load test & tune performance on your API》

本文基于Mark在APIStrat/APIDays 柏林站的演讲,视频可以在YouTube上看,如果你可以翻墙的话。

这是如何对API进行负载测试与调优的第2部分。在第1部分中,我们聊了配置测试环境,聊了要测量的指标以及测量这些指标的不同方法。我们还了解了使用哪些测试工具,以获得有关我们的API执行情况的真实数据。

我们现在将研究如何将API安全地暴露给公众,同时确保其性能不受影响。

如何为你的API添加访问控制层

我们已经有了高性能的API了,但如果万一有人以超过16000次请求/秒的速度向服务器发送请求怎么办?你如何能防止API用户向你的API发出爆炸性请求?如果没处理好,将会影响其他用户对API的使用。

解决方法有很多,最简单的就是在你的API服务器建立限速系统。我们认为应该尽可能地降低系统之间的耦合度,所以最好在你的系统中有一个单独的层,这个单独的层专门负责处理限速。

这时候API网关就可以派上用场了。API网关是解决管理API访问问题的通用架构解决方案。它除了用来做访问控制,还可以充当协调与开放内部API不同接口的整合层。

在本文案例中,我们将使用我们自己的API网关,它与3scale平台一起使API提供商能够以安全的方式向外界开放他们的API。它可以很方便地对API接口进行身份验证与设置限速。

有几种方法可以将您的API与3scale集成,我们这里选择基于Nginx的高性能代理部署API网关。我们将会在我们的API服务器之前部署3scale API网关。使用代理的原因不仅仅是性能问题:由于它部署在我们的API之前,那些没经身份验证的或高于我们允许限制的流量请求在到达API服务器之前将会被代理拒绝掉。这让我们可以更专注考虑我们的API服务器,这样我们的API服务器就可以按我们预定的流量负载来设计,不用担心超过这个流量会有什么意外发生,其他的事就交给API网关处理。当然,万一我们的API服务器负荷处理量增加或者是用户数量意外增长时,我们也能在3scale的管理平台上调整限制设置。

作为工程师,在架构中增加扩展层要谨慎。所以我们这里的目标是确保这个扩展性不会对我们的API性能造成影响。

我们会在与我们的API服务器使用相同类型配置的AWS实例上部署网关,一个带有2个虚拟核的c4.large。设置网关很简单,我们可以借用AWS服务市场上我们的AMI映像

在3scale平台上配置好API后,我们会拿到定制的Nginx配置文件,我们用它来启动API网关。第一步将使用默认配置运行我们之前做的相同测试,请求地址要小修改一下,现在多包含了一个带有API 密钥的参数。

GET http://our-api-gateway.com/question?user_key=ABCD123

以10000次请求/秒速度运行和以前相同的测试,我们会命中几个错误。 Loader.io最终由于大量的错误停止测试。

这些都似乎是500状态码内部错误或其他未指定的网络错误。 我们查过API服务器没有返回任何错误,所以问题的源头可能是Nginx,其中日志显示大量的这些:

2015/04/12 23:07:10 [alert] 2573#0: *147508 256 worker_connections are not enough while connecting to upstream, client: …, server: , request: “GET /question HTTP/1.1”, upstream: “http://…/question”, host: “…”

Nginx需要为每个请求至少打开两个连接,一个到客户端,另一个到代理服务器。 它还需要打开连接到3scale,但不是每个请求都要连(我们用的是增强版的3scale API网关,它能批量授权和生成报告)。

考虑到这一点,以10000次请求/秒的速率,Nginx将需要保持的同时打开连接的数量将远高于256。

调整API代理网关以达最大性能

配置nginx的worker_connections可配置配置同时打开的连接数。该设置也高度依赖于底层系统:Nginx不能打开比系统可提供的套接字更多的连接。如果我们想提高数字,有几个设置要修改。

修改文件/etc/security/limits.conf:

# 如果你没配过以下参数,请在文件底部增加以下行,生效需要重启系统

* soft nofile 200000

* hard nofile 200000

修改文件/etc/sysctl.conf:

# 增加打开文件的限制数

# 改完后运行这命令以生效:  sudo sysctl -p /etc/sysctl.conf

fs.file-max = 5000000

改完以上内容后,你接下来可以修改nginx的配置文件nginx.conf:

worker_rlimit_nofile 100000;

events {

worker_connections  100000;

}

Nginx和系统级的优化还有其他一些方法,你可以在Nginx的官方文档中查阅。

在本文案例中,下面的配置修改,极大提高了网络资源的利用率:

(1)在upstream中启用Keep alive,这个需要将HTTP协议设为1.1版,这也是Node.js默认使用的版本。

(2)减少tcp_fin_timeout以最小化TIME_WAIT状态中的连接数,这样我们就不需要很多过时的连接,记得也要启用tcp_tw_reuse。

(3)将worker_processes设为auto ,这样Nginx就可为每一个可用CPU内核启动一个worker进程。

还有很多设置可以提高Web服务器的性能,特别是在系统级的设置。你可以在这里对照一下更为完整的优化配置列表。建议你要对你的系统环境有足够的了解,才能应用这些优化配置。

还有其他一些配置对负载测试环境的影响比在生产环境中影响更大,比较容易产生误导性的测试结果。比如,增加Nginx中 keepalive_requests 的值可以让一个keep-alive连接发送更多的请求。在我们的测试标准中,所有的负载生成都是从单一源发出了,如果增大这个值,明显会比负载来自多个源更有效率。

检查一下优化设置是否生效,我们可以在Loader.io上以60秒运行10000请求/秒的测试。测试结果如下:

测试结果现在没问题了,没有500错误或网络错误。我们达到了我们预期的速率。不过有点微小的差别,就是曲线在延迟增加的地方有些波峰突起,这些突起点是当Nginx需要向3scale反馈数据时发生的,这也影响了当时正要处理的几个客户端请求。网关中的报告生成是由每个客户端完成的,这就是为什么这里的影响非常明显,因为我们从单个客户端生成大量流量。此外,在测试期间这些报告成生的批处理也是相当频繁地进行。如果我们将周期设置的比测试持续时间更长,基本上我们一访问完API,结果就马上出来。

最后,我们用wrk重新来做和前面同样的测试。结果发现通过API网关的性能和我们直接访问API的性能基本一致。但还是有一个比较大的区别,我们现在在我们的API前面多了一层,这一层让我们可以控制它,可以设定速率限制,可以身份验证,可以看到API的使用情况统计分析。而这一切都不需要再修改我们的API代码。

运行1分钟测试 @ http://api-gateway/question

4 threads and 1000 connections

Thread Stats   Avg      Stdev     Max   +/- Stdev

Latency   85.27ms   90.29ms   1.27s    92.76%

Req/Sec     3.98k   588.91     4.27k    64.50%

Latency Distribution

50%  85.75ms

75%  96.61ms

90%  127.49ms

99%  230.90ms

955320 requests in 1.00m, 194.17MB read

Requests/sec:  15942.54

Transfer/sec:      3.23MB

总结

通过这两篇文章,我们讲述 如何对API进行一个有效的负载测试。我们先要配置好测试环境,为准备好测试提供了一些建议。然后我们介绍了市面上以及开源社区里的几个负载测试工具。我们测算出API能实现的峰值性能,同时在性能不受损的前提下增加了API的访问控制层。

从本文的测试中,我们总结出以几个关键点:

(1)在运行测试之前,你要先定好目标,这些目标最好是基于你目前流量数据来定的。这有助于你确定你的API要达到的性能目标线。

(2)要花点时间准备好一个可测量的稳定基线环境。如果你一开始就没弄好,你的测试结果就毫无价值。

(3)别让测试工具成为你测试的限制因素,要研究了解每个测试工具的特性(比如单线程、多线程),多个测试工具的测试可以让你更全面的了解你的API性能。

(3)当你微调了你架构中某部分组件的性能时,你需要对架构中所有部分进行观测。如果限制因素在系统级别上,那么在API层做优化调整也没用。

(4)有一个API网关管理层可以让你更安心,因为管理层可以安全保护好你的API,API只会获得可预测的流量,不会受爆炸性的意外流量影响。对于非可预测的流量,API网关会处理好。

希望本文能给你带来帮助!

本文来自马克在 APIStrat / APIDays 柏林站的演讲整理。


本文译自:How to load test & tune performance on your API (Part II)

如何对API进行负载测试与调优(1)

前言

这几年API的作用不断演化,以前API还只是用来做内部系统之间的集成点,但现在API已成为一个公司的核心系统,一个构建于Web和移动端应用之上的核心系统。

当API仅只用来处理后台的任务(例如生成报告),那么性能差点也不是问题。但是如今API慢慢地发展成为连接服务与终端用户的核心纽带。这种关键性的角色变化表明了一个重要的观点:那就是API的性能真的很重要。

如果API数据源响应快,前端的应用程序的设计好点或差点影响不大,要是响应慢如蜗牛,前端的设计再出色也是然并卵。现在我们的客户端应用展示的数据源可能都是来自多个API响应内容的聚合,性能对这种微服务构架来说真的非常重要。

可以毫不夸张的说出色的性能就是你API提供的最好功能。我们知道向目标改进的唯一正确的方法就是找到问题的关键点,或者叫关键路径,并不断迭代测量和调整你的架构系统,直到系统达到预定的目标。对于API来说,测量和提高性能的过程就是负载与压力测试的过程。

本文将重点介绍如何对你的API进行负载压力测试。我们会以一个简单的、未测过的例子开始,然后再添加一个访问控制层,要确保一切都经过严格测试,做好处理真实流量的准备工作。OK,开始吧!

准备工作

首先我们要明确要测试什么,可以是对你所有的API接口,或者是对单个API接口,或是对需要排除故障或改进的API接口的常规测试。

本文的其部分,我们将使用一个示例API。这是一个棋牌类游戏的Node.js API。它有三个API接口:

/question – 返回一个随机黑牌

/answer – 返回一个随机白牌

/pick – 返回一对随机的问题与答案

你测试用的负荷情况越和真实环境的越类似,你的负载测试就越有用。如果你不知道实际流量有多少或者你不知道负载在所有接口上是否都一致,那么就算你知道你的API可以保持400 请求/秒的吞吐量也没啥鸟用。

所以,你应该先从收集你API的使用数据开始。你可以直接从你的API服务日志或者从其他你在用的应用性能工具(例如New Relic)中获取数据。在对你的API进行第一次测试之前,你应该对以下问题做到心中有数:

(1)每秒请求数的平均吞吐量(Average throughput in requests per second)

(2)峰值吞吐量(您在某段时间内获得的最大流量是多少?)(Peak throughput)

(3)API各接口的吞吐量分布情况(有没有一些接口的流量远超其他接口?)

(4)用户的吞吐量分布情况(少数用户产生大多数的流量,或者是更均匀分布?)

另外还需要考虑的一个关键点是,在测试期间将要模拟的流量会是怎样的,主要考虑点是:

(1)重复负载生成(Repetitive load generation)

(2)模拟流量模式

(3)真实流量

通常我们最好以最简单的方法开始测试,然后逐步演化到更为接近真实环境的测试。我们可以先用重复负载生成来做为API接口的第一个测试,这样不仅可以验证我们的测试环境是否稳定,更重要的是可以让我们找到API能承受的最大吞吐量,这样我们就可以知道API可以达到的性能上限是多少。

找到你的API性能上限值后,你就可以开始考虑如何将你的生成的测试流量塑造得更接近真实环境。使用真实流量来测试是最理想的,但实际操作不太可行。要模拟真实流量比较难,也太花时间。所以我们有一个折中点的方法:先研究你的流量分析数据,并做一个简单的概率模拟。比如你有100个API接口(提示:原文endpoint在这里我译为接口,翻译成端点也可以,不过译成接口感觉更容易理解),你检查了上个月的使用情况,发现80%的流量来自20个接口,其中3个接口占用了50%的流量。那么你就可以创建一个遵循这种概率的请求列表,并提供给你的负载测试工具。这样做就相对快多了,并且它相对比较接近你真实负载,可以显示出你实际环境中可能遇到的问题。

最后,如果你拿到你要测试的API的真实访问日志,你就可以用它们来做最接近客观现实的测试。我们待会儿要讨论的大部分负载测试工具,都是接收一个请求列表作为输入文件。你可以用你的访问日志,稍微做一个格式调整就可以匹配每个测试工具所需的格式。搞定这个你就可以在测试环境中轻松重现你的生产流量。

配置你的负载测试环境

好了,你清楚了你要测试什么鬼了,准备工作的最后一步就是配置好你的测试环境。你需要一个专用的测试环境。如果你不怕被你老板骂的话,或者比较任性,你也可以直接在你的生产环境中进行性能测试,不过出问题别说哥事先没跟你说清楚哈。

如果您已经设好一个预生产或沙箱环境,并且你的API也在上面运行了,那么你就万事俱备了。因为本文要用示例API,我们会在AWS的服务实例上设置我们的环境。

在我们的例子中,我们使用一个简单的API,不需要从磁盘读取或在内存中保存大型数据集。我们选择Linux C4.large实例就够了。

注意:我们对比过其他相似处理资源数但内存更大的AWS实例,但实际测试中内存大部分没使用,所以我们选了C4.large

接下来,我们将一个配好的负载测试实例(服务器)运行起来,这只是一个运行模拟测试程序的服务器,它会通过从多个并发连接重复发送请求到我们的API服务器。你需要模拟的负载越高,机器的性能就要求越高。再次,这也是一个CPU密集型工作负载。这里我们选择具有4个虚拟核,16个 ECU的优化处理器的c4.xlarge AWS服务器

我们选择在相同的可用区内部署所有实例(API服务器与测试服务器在同一个区/机房),这样可以将外部因素对我们测试结果的影响降到最小。

选择测试工具

我们有一个沙箱环境来运行我们的API,同时也有另一台服务器准备开始负载测试。如果这是你第一次做性能测试,你一定会想知道什么是最好的方法。在本节中,我们将会分享我们如何选择工具,同时也会介绍一下目前市面上一些公认比较好的工具。

JMeter

在人们意识当中,首当翘楚的估计是Apache JMeter,这是一个开源的Java程序,他关键的特性就是提供一个强大而完善的创建测试计划的GUI。测试计划由测试组件组成,测试组件定义了测试的每一个部分,例如:

(1)用来注入负载测试的线程

(2)参数化测试中使用的HTTP请求

(3)可添加侦听器,象widget测试组件那样,可以以不同的方式显示测主式结果

优点:

(1)它是功能性负载测试的最好工具。你可以设定条件来为复杂的用户流建模,还可以创建断言来验证行为。

(2)轻松模拟复杂的http请求,比如请求前的登录验证或文件上传

(3)可扩展性强,有很多社区插件可以修改或扩展内置的行为

(4)开源并且免费

缺点:

(1)GUI学习曲线陡峭,一大堆的选项,在你运行第一个测试之前你得了解大量的概念。

(2)测试高负载时,操作步骤很麻烦。你需要先使用GUI工具来生成XML测试计划,然后在非GUI模式下导入测试计划运行测试,因为GUI会消耗掉本用于生成负载的大量资源。你还需要注意所有的侦听器(收集数据与展示测量的组件)哪些要被禁用或启用,因为它们也很耗资源。测试结束后后,你需要将原始结果数据导入GUI以才能查看结果。

(3)如果你的目标是测试一段时间内的持续吞吐量(例如在60秒内每秒请求1000次),那么很难找到正确的并发线程数量和计时器来求出一个比较稳定的数值。

JMeter只是我们在开始测试时用的工具,我们很快开始寻找其他替代方案。原因是,如果你的目标是在Web应用上压力测试复杂的用户流,那么JMeter可能是最好的工具,但如果你只是需要在一些HTTP API接口上进行性能测试,那用它就是杀鸡用牛刀了。

Wrk

Wrk是一款和传统的Apache Benchmark(最初用来做Apache服务器的测试工具)非常相似的工具。wrk和ab完全不同于JMeter:

(1)一切都是可以通过命令行工具配置和执行的。

(2)配置少但强大,只有基本生成HTTP负载的必要几项配置

(3)性能强悍

然而,和传统ab工具相比还是有几个优势的地方,主要是:

(1)多线程,所以能利用多核处理器的优势,更容易生成更高的负载

(2)利用Lua脚本很容易进行扩展默认的行为

不好的地方,主要是生成的默认报告在内容与格式上都受到限制(仅文本,无绘图)。当你的目标是找到你的API可以处理的最大负载量,那么wrk是你最佳选择工具。wrk用起来很快就可以上手。

Vegeta

Vegeta是一款开源命令行工具,但它采用的方式不同于我们以前所见的工具。它专注于如何达到与维持每秒请求数速率。也就是说它侧重在测试支撑每秒X次请求时API会有怎样的服务行为,当你有实际的数据或对你将要达到的峰值流量有个估算时就非常有用,你可以用于验证你的API是否能满足你的需求。

SaaS 工具

正如你之前所看到的,运行一个简单的负载测试需要准备好配置环境。最近有些产品提供负载测试服务。我们试过两个,Loader.ioBlazemeter(话外:阿里也有性能测试工具PTS,老外估计没试过)。

注意:我们只试了这两个工具的免费版,所以得到的测试结果仅适用于免费版的限定。

Blazemeter

这个产品和我们前面提到的JMeter一样有同样的毛病:如果你只需要用在高负载测试,你需要在GUI界面上创建测试计划,然后在另一个运行非GUI模式的JMeter中导入这些计划。Blazemeter允许你上传JMeter的测试计划到他们的云端并运行,但可惜的是免费版只能设置50个并发用户。

Loader.io

它是一款SendGrid出品的简单而强大的云负载测试服务工具。它有你所需要的功能和漂亮的可视报告。 Loader.io 的免费版还是不错的,每秒最多可以有10000次请求的吞吐量,你基本上就可以用它来运行一个真实的负载测试。

我们推荐使用多个工具,以便可以多重检查我们的测试结果,不同的工具有不同的功能与方法,可以更多方面地反映测试结果。

建立测试基线

我们先尝试找到我们的API可以承受的最大吞吐量。在这个吞吐量下,我们的API服务达到最大CPU利用率,同时不会返回任何错误或超时。这个吞吐量就可作为我们后面测试要用的每秒请求数。

同样,重要的是要注意到:CPU是限制因素之一,但你也还必须清楚地知道哪些资源会成为你API的性能瓶颈。

我们有必要在API服务器上安装一些工具,以便我们在测试过程中监控资源的利用率情况。我们使用 Keymetrics.io 和 PM2 模块。

我们的Node.js应用运行了一个非常简单的HTTP 服务。Node.js是单线程设计的,但为了利用c4.large AWS实例中提供的双核,我们使用PM2的集群功能来运行应用程序的两个工作进程。

由于我们的API是完全无状态的,所以很容易使用PM2的 核心集群模块(PM2在内部直接使用)。PM2提供的集群功能提供了不错的快捷命令来start/stop/reload应用程序,也可以监控进程。

首次运行

我们先使用Loader.io对API进行测试。以下是持续30秒,每秒10,000次请求的测试结果,10000次请求是Loader.io免费版中允许的最大吞吐量。

在测试期间,我们观察到API服务器的CPU处理器在测试期间只有几次达到100%的容量。

这表示我们的API可能还可以处理更高的吞吐量。我们接下来通过运行wrk进行第二次测试证实了这一点。我们的目标就是要将我们的API服务器n推到极限。

wrk -t 4 -c 1000 -d 60 –latency –timeout 3s http://api-server/questions

这里是我们对这个测试做了多次重复测试的结果:

Running 1m test @ http://api-server/question

threads and 1000 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 62.23ms 30.85ms 1.35s 99.39%

Req/Sec 4.07k 357.61 5.27k 94.29%

Latency Distribution

50% 60.04ms

75% 63.85ms

90% 64.17ms

99% 75.86ms

972482 requests in 1.00m, 189.89MB read

Requests/sec: 16206.04

Transfer/sec: 3.16MB

结果表明,我们的预感被证实:它达到16,206请求/秒,同时保持合理的延迟,第99百分位只有75.86毫秒。 我们将这作为我们的基准最大吞吐量,因为这一次我们看到了API服务器的最大容量处理能力:

接下来

我们刚看到用一个简单的方式来找出你的API可承受的最大流量负载,同时在这过程中我们介绍并讨论了我们看到的一些工具。

请继续关注本文的第二部分,我们将介绍如何控制流量,不要让随随便便一个客户端就可以轻松搞跨您的API。 我们将展示如何通过在架构前端添加代理来确保我们的API的性能不受影响。

本文译自:How to load test & tune performance on your API,转载请声明出处!

ReactNative商城系统

之前用ReactJS写了个商城系统http://m.angelbaie.com,这段时间学习React Native,弄了几个界面,搞了个简单的APP,有学习需要的可以自行下载!

程序地址:https://github.com/misnet/react-native-shop

Android APK文件下载:react-native-shop.apk

IOS版未测试与发布过。

安装


npm install

安装相应的软件包

  • react-native-modalbox
  • react-native-root-toast
  • react-native-loading-spinner-overlay
  • md5
  • lodash
  • es6-react-mixins
  • reflux

重要提醒

本APP在我自己的Android 6.0(华为荣耀6Plus)上测试过,未在其他Android设备或IOS设备上测试过,如有问题,请反馈或自行解决。

本APP基于reflux的flux设计思想实现,对reflux不清楚的请自行查询相关资料

API

本APP使用服务端的API和http://m.angelbaie.com的一样。你可以手机浏览器打开http://m.angelbaie.com或在PC上打开http://m.angelbaie.com了解

APP目前实现的功能

  • 用户登录
  • 用户注册(发送短信验证码,只支持中国手机号码)
  • 列出商品
  • 修改用户资料(包括头像、呢称、性别)
  • 多语言支持(目前暂只能在Config.js中修改语种,支持en_US、zh_CN)

测试账号

用户名:13000000000
密码:123456

ReactNative中navigator.pop后如何实现数据更新

问题:不同Scene之间,如何保持数据一致性?后一个页面数据与前一个页面的数据有关联时,当后一个页面做个update操作并在navigator.pop()后,前一个页面的数据如何自动update?

ucenter profile updatephoto

场景:上图A界面显示了用户的头像,点击头像进入B界面,点击B界面的头像进入C界面,在C界面进行头像上传操作,头像上传完毕后,从C界面返回B界面时,此时B界面的头像要能自动更换成新的,同理再从B界面后退到A界面时,A界面的用户头像也必须是更新后的新头像。问题来了,界面的后退操作一般都是使用navigator.pop(),这个方法只实现后退,react-native官方文档上没显示navigator.pop()可以带参数做回调操作,那么要如何解决A、B界面在C界面做了更改头像后自动更新头像的操作呢?

解决方案1:
A界面进入B界面时,带上回调参数,如
this.props.navigator.push({‘id’:’b’,’callback’:this.refreshAAvatar}
在B界面进入C时,带上回调参数,如
this.props.navigator.push({‘id’:’c’,’callback’:this.refreshBAvatar});
在C界面完成修改操作后执行navigator.pop()之前执行
this.route.callback();即可让B界面完成刷新头像操作
在B界面点左上角的后退箭头时,判断是否有头像更新,有的话,调用this.route.callback(),通知A界面更新头像

通过页面之间做回调处理,似乎可以解决此类问题,但是当多个页面都需要做数据刷新操作时,这样的回调就很繁锁,而且左上角的后退按钮本来是一个很单一职责的操作,现在由于更新需要,要被“承担”更多的职责,明显提高了界面之间的耦合度,这样的设计处理不理解。

解决方案2:
借用DeviceEventEmitter的事件侦听处理机制,在A、与B页面的ComponentDidMount时,添加侦听器,在ComponentWillUnmount时删除侦听器
A界面:

import {DeviceEventEmitter} from 'react-native';
//…
componentWillUnmount(){
this.subscription.remove();
};
componentDidMount(){
this.subscription = DeviceEventEmitter.addListener('changeAvatar’,this.refreshAAvatar);
};
this.refreshAAvatar(data){
Console.warn(‘要更新的头像地址’,data);
};

B界面:

import {DeviceEventEmitter} from 'react-native';
//…
componentWillUnmount(){
this.subscription.remove();
};
componentDidMount(){
this.subscription = DeviceEventEmitter.addListener('changeAvatar’,this.refreshBAvatar);
};
this.refreshBAvatar(data){
Console.warn(‘要更新的头像地址’,data);
};

C界面:

import {DeviceEventEmitter} from 'react-native';

//当成功修改用户头像后,调用事件通知
DeviceEventEmitter.emit('changeAvatar’,avatarUrl);

在本解决方案中,A、B界面启用了侦听,当任何有修改头像时,只要修改者发送changeAvatar事件,就可以通知所有侦听changeAvatar事件的界面,是不是比解决方案1更简单?

react datetime-picker 手机版

在手机上选择日期与时间的控件很多基本上都是网页版的,不适合手机浏览器用,react-datetimepicker-mobile 是一款基于React和JQuery的日期时间选择器,可以用来选择日期或日期+时间,可以指定日期格式。 阅读更多

Atom编辑器中自动编译jsx文件

Facebook之前有提供jsx工具,可以通过命令行实现jsx文件编译成js文件,babel的强大让facebook放弃了jsxTransform工具,直接用babel来实现jsx到js的编译,不过通过使用babel命令行来进行jsx的编译还是不方便。幸运的是现在atom可以安装language-babel插件来实现jsx的自动编译,jsx编辑时一按保存按钮就会自动生成js文件和sourceMap文件,真是高大上。
安装language-babel的过程就不说了,简单说一下配置:
(1)在Atom的language-babel的Setting中将Allow Local Override打勾
babel

(2)在你的项目根目录建立一个.languagebabel文件,配置类似如下实例:
{
“babelTranspilePath”:”./assets/js/app”, //jsx文件编译成js文件的存放目录
“babelSourcePath”:”./assets/js/src”, //jsx文件的源目录
“transpileOnSave”:true, //在保存时是否自动编译
“createMap”:false, //是否创建sourceMap文件,有用sourcemap的可以true
“babelMapsAddUrl”:false, //是否在生成的js最下方添加sourceMap的地址
“createTargetDirectories”:false, //当生成js文件时,对应的目录不存在,是否自动创建
“createTranspiledCode”:true //为true时才会编译
}

(3)用atom编辑jsx文件时,要注意右下角下图所示这个地方,系统要以Babel ES6 JavaScript方式打开的才会使用到language-babel插件,如果不是,请点击更改。
babeles6

配置完毕后,你可以测试一下,写一个jsx文件,然后按保存,如果正常的话,系统会在右上角弹出对话框,告诉你成功编译了。
alert

Di18n 一个前端多国语言化的js小程序

项目地址:
https://github.com/misnet/Di18n

特点

  • 采用json形式的翻译对照
  • 支持指定变量替换
  • 支持数值型变量时,可定义目标语言的多种复数形式
  • 支持AMD规范
  • 未定义译文时,直接使用源文

阅读更多

用javascript来开发桌面应用

Javascript绝对是这世上最牛的语言,没有之一,上天入地无所不能,10几年来一直主做服务端开发,自从研究了react后,就深陷前端开发,感觉比服务端开发更有意思。

桌面应用开发一直是Web开发人员的弱项,以前有phpGTK,观摩过,但总觉得界面奇丑,拿不出手啊。现在有Electron,可以用javascript来开发桌面应用,用Web的语言与工具就可以实现桌面应用的效果,按女儿的说法,真是棒棒哒!言归正传,总结一下用Electron的开发用法: 阅读更多

演示用,多页面动态切换多个URL地址

//设置好要播放的地址
fancyWindows.setUrls([
'http://www.nanhai.gov.cn/cms/sites/nh_ggzy/ipad/index_zfcg.html',
'http://www.nanhai.gov.cn/cms/sites/nh_ggzy/ipad/index_gczb.html',
'http://www.nanhai.gov.cn/cms/sites/nh_ggzy/ipad/index_tdjy.html'
]);
fancyWindows.play();

阅读更多