共享充电线是共享经济的一部分，具有比共享充电宝成本低的特点，特使是在KTV酒店独立环境有更大的竞争力。 一条充电线的价格在15元左右，按照使用一次2元，10%的使用率，75天回本，如果按照一年的寿命，一年4倍利润。是相当可观的。 方果科技提供共享充电线全套技术，欢迎合作。13215994088.

    接触PHP六年，说一说swoole对PHP前景影响，最近发现PHP的两大缺点：1、无法常住内存。2、长链接。无法常驻内存就无法实时监控系统，以及与系统实时通信，长链接也是实时通信必备条件。swoole利用C重写底层从根本上解决这两个问题。      在物联网时代，更能体现PHP的两大弊端。大量的PHP开发人员希望解除物联网就无法逾越这两个问题。swoole的诞生让PHP开发者看到了希望。PHP也为物联网企业解决了快速开发的问题。

　2014年下半年，微信捧火了HTML5小游戏，自此国内各行各业开始对HTML5保持持续高涨的关注。2015年是国内HTML5行业迅速发展的一年，在媒体大肆渲染“互联网寒冬”之际，HTML5作品的生产数量和传播广度却居高不下，为寒冬增添一把热火。 　　如图，根据百度指数对关键词“HTML5”搜索趋势结果，2015年“HTML5”的指数约是2014年的1.5倍;而HTML5的简单说法“H5”在2015年的检索量是前一年的2倍多，直逼“HTML5”。 　　2015年，国内HTML5的传播仍以移动端为主，但简单的翻页这种低层次的设计已经不再适应大部分受众的需求，HTML5平台也开始由简单的工具应用逐步转型。其中，发展得比较快的是面向商企用户的iH5，自主研发引擎，并于2015年年底添加即时通讯功能和线上交易机制。 　　为什么是HTML5? 　　Web应用开发新标准 　　HTML5，第五版超文本标记语言，于2014年10月由万维网联盟(W3C)发布为正式推荐标准。它是HTML自1991年问世以来，最具变革价值的技术规范，历经多年修订与完善才制定完成。 　　过去，Web开发面临两种困境： 　　(1)不少人质疑Flash的安全性等问题，却找不到替代它的合适插件; 　　(2)工程师们抱怨PC端和移动端应用的多次开发，仍旧得为微软、苹果、安卓等系统设计不同方案。 　　而HTML5提供了良好的解决方案。与JavaScript、CSS等紧密结合后，HTML5能使浏览器不需要类似Flash的插件也能实现桌面应用的交互效果，它的跨平台可用性更令应用的一次开发成为可能。 　　如上图，Youtube使用HTML5的video元素进行标记后，网页不需要第三方插件就能播放音视频等。因此，HTML5的兴起具有非常深远的意义，它已经从简单的标记语言化身为Web应用开发的先驱。 　　HTML5应用现状 　　从硬件角度来看，国内手机和平板两种移动设备应用最广，PC端次之，紧接着是电视和游戏设备。 　　从软件角度来看，桌面浏览器对HTML5的支持高于移动浏览器，最高可达95%;而从整体上而言，移动浏览器对HTML5的支持却优于桌面浏览器。 　　HTML5具有较好的浏览器向后兼容性，开发者能对浏览器不支持的情形设计各种各样的回退方案。因此，HTML5页面的实际显示性能与开发者、制作平台密切相关。 　　2015年，越来越多公司在HTML5品牌推广上进行布局。6至7月份起，鸡汤、自媒体等个人作品呈下降趋势，商企用户作品则保持高速增长。在商业需求的驱动下，HTML5页面设计的目的性更强，获得最好传播效果的基本是经过一定时间策划，在团队操作下有针对性地进行投放的企业案例。 　　相对应地，原有HTML5平台也进行了大面积升级。从平台性质而言，HTML5平台可分为轻营销模板类、功能引擎类和基础工具类三种，分别以易企秀、白鹭引擎和iH5为代表。 　　三类HTML5平台的特点如下—— 　　(1)轻营销模板类：提供类似PPT页面切换的HTML5制作工具，通常面向C端(个人)用户，部分为B端(企业)用户。该类平台的数量较大，只适用于轻度营销，所能提供的页面动态效果局限于翻页。 　　(2)功能引擎类：提供HTML5网页的开发引擎，通常面向B端用户。该类平台主要提供基于Canvas(画布)的游戏引擎，适用于轻游戏的开发，依赖于开发者。 　　(3)基础工具类：提供用于页面交互的HTML5可视化编辑工具，主要面向B端用户，部分为C端用户。该类平台只有iH5，采用自主研发的闭源引擎，应用领域广泛，涵盖轻度营销、重度营销、媒体电商内容应用、视频、动画、游戏等方面。 　　与浏览器多采用谷歌开源引擎的状况相近，国内HTML5平台基本使用国内外开源框架或引擎。但和浏览器面向网页内容显示，只需提供高性能的技术支持不同，HTML5平台面向的是HTML5制作或开发，需要对网页质量负责。因此，使用开源框架或引擎意味着这些HTML5平台进一步拓展业务会比较被动，容易面临同质化的困境。 　　三类HTML5平台的对比 　　因为整体上移动端浏览器对HTML5的支持优于PC端，2015年HTML5平台主要面向移动端网页的制作和开发。 　　如上表，三种HTML5平台以PC网站、APP和软件三种形式提供制作或开发工具，成品为网页或HTML5源码。由表可见： 　　(1)轻营销模板类HTML5平台只能做轻度营销，能实现翻页等简单动效，分为场景展示、电子出版和动画制作三种。如下图为易企秀桌面编辑界面，该类平台最大的共同点在于工具结构以页面为基础，与软件PowerPoint架构相近，能通过增减页面、使用功能组件和点击快捷菜单来调整内容。 　　(2)功能引擎类HTML5平台的用户专指性很强，主要是有开发经验的技术人员。下图为Egret Wing软件设计师视图下的基本架构，使用HTML5引擎把基础代码流程化，再借助第三方集成开发环境Adobe Air构建可视化工具，就能通过让用户使用软件组件来简化开发过程。 　　(3)基础工具类HTML5平台提供底层交互型产品，开发目的、设计原理和实现思路都以交互为基础，国内只有iH5。iH5于2015年9月上线，提供HTML5制作工具、工具培训和作品交易等服务。它本质上封装了DOM(文档对象模型)引擎的一个集成开发环境，使用者以设计师为主，适合广告公司、大型媒体公司和公司市场部等使用。 　　如上图，iH5提供的是舞台、屏幕、页面、多媒体素材、事件、数据库等对象组件，而不是构建好的模块组件。在提供可视化编辑的前提上，它最大程度还原了HTML5页面的开发过程，具有较高的拓展性。由于提供底层交互功能，它的应用领域较广泛，能用于微信推广、网站建设、轻游戏设计、轻APP开发和视频交互等多个方面。 　　同样是HTML5规范，对HTML5技术与性能的取舍成为国内HTML5平台工具定位和提供服务的差别所在。 　　HTML5行业发展的趋势 　　伴随着HTML5兴起的是Flash的没落，HTML5能打败在多媒体领域称霸多年的Flash，除了移动设备的跨平台性和较好的多媒体支持外，它的应用范围也广于Flash。比如，Flash动画作品的复用性极低，基本没有模板市场，而HTML5却能作为基础填充材料，用来制作报纸图文等模板。 　　参考Flash发展的演化路径并结合HTML5的新特性，HTML5近几年会在重度内容、网页游戏、垂直领域解决方案和内容直接填充四个方面有所突破。 　　(1)内容往重度化方向发展。 　　重度营销并不完全意味着大项目、高预算、长周期、大团队，而是相对轻度营销以用户生产内容为主，它更注重专业内容的生产。在用户对页面交互能力和HTML5拓展功能的要求提高之际，轻度营销的市场份额会逐渐降低，往重度营销内容转化。 　　(2)网页游戏往交互游戏方向发展。 　　尽管HTML5游戏具备无需下载、包含社交属性、开发成本低等优势，但如果没有充分利用HTML5的新特性，加强移动游戏的交互能力，它很难在游戏市场中异军突起。由此，网页游戏未来更有可能结合HTML5优良的通信功能，往跨屏互动等交互特征更明显的形式发展。 　　(3)垂直领域解决方案往在线应用方向发展。 　　与HTML5行业密切相关的垂直行业主要包括在线教育、电商和流媒体三种类型。 　　以世界最大的在线课程平台Coursera为例，授课视频即使用HTML5实现“课间小测”。如下图，在Coursera网站上，当视频播放到特定节点时会出现与课程相关的问题，提供用户选择答案，记录答题情况并反馈答题结果。 　　(4)传媒业往内容直接填充方向发展。 　　国内HTML5制作工具基本都提供模板服务，这与HTML5网页较强的复用性有关。网页基础架构设计完成后，修改源码中各元素的参数便能替换素材、改变对象属性，因此HTML5网页能用于制作基础填充材料。在HTML5模板的帮助下，新媒体内容能通过应用母版进行编辑，用户只需后期进行图文内容的替换，因此很有可能成为传媒业转型的契机。 　　反观国内不同类型的HTML5平台，只有以HTML5提供的新特性为根本，着眼于底层交互才可能适应各行各业对网页开发的需求。因此，基于HTML5元素和属性进行设计的基础工具，未来更有机会占领尽可能多的市场份额。

　　这篇文章要报道的并不是“新闻”，因为W3C早已开始着手CSS变量(又称‘自定义属性’)方面的工作。而作为CSS4非正式标准的一部分，Mozilla早在Firefox版本号还是29的时候就已经支持它了。至于Google，则要追溯到11月初，当时该公司主要开发人员之一的Addy Osmani宣布了率先在Chrome Canary中引入对CSS变量的支持。 　　Mozilla最先在Firefox29中加入了对CSS变量(CSS variables)的支持，而开发者们可以在他们的CSS代码中部署使用了多年的compile-to-CSS语言，比如Sass、LESS、或者Stylus。 　　近段时间，许多人开始迁移至PostCSS。在面对CSS语法时，这些功能提供了更多的动态表达式。 　　如果W3C想要迎头赶上，最好先瞅瞅CSS子集语言现在都能干些什么、而不是它们几年前你能够做些什么(这里指的是对混合类[mixins]、局部变量[partials]、以及更复杂操作的支持)。 　　尽管很大程度上仍有需要，但当前已经没有多少开发者会写一些切实的CSS代码了。W3C确实在CSS自定义属性上落后了6-7年，不过它仍可让CSS变得更加强大。

web改变了，因而我的技术堆栈也变了。貌似我的堆栈变回到了roots。 20年前，我从HTML和JavaScript开始，再到使用VBScript的经典ASP。 2001年，我开始陶醉于ASP.NET和VB.NET，并用到了产品中，直到2006年底才不再这么干。2007年年底，我开始使用C#编写ASP.NET。HTML和JavaScript仍然参与其中，但多多少少被封装在第三方控件中，并且jQuery当时是JavaScript的别名。JavaScript的一切都是jQuery。ASP.NET WebForms感觉巨大又不是很灵活，但它能有效工作。后来——2010年——我用Silverlight、WinForms和WPF做了很多东西。 　　ASP.NET MVC出现了，web这个东西开始再次比ASP.NET WebForms感受更自然点。从一个ASP.NET开发人员的角度来看，web开始变得更好：更加干净、灵活、轻便和自然。 　　但也出现了一些新的东西。一些来自于ASP.NET世界之外的东西。强大的JavaScript库，如KnockOut、Backbone，以及后来的Angular和React。第一个单页应用程序框架(对不起，我不想提蹩脚的ASP.NET AJAX…)出现了，UI逻辑从服务器转移到了客户端。(好吧，我们确实在2005年搞回了一个很酷的SPA，但我们没有想过如何用它创建一个框架。) 　　NodeJS通过在服务器上使用JavaScript再次改变了世界。你只需要两个不同的语言(HTML和JavaScript)，就可以来创建很酷的web应用。我不怎么对NodeJS感兴趣，除了在后端使用它，因为一些工具基于NodeJS。也许这是一个错误，谁知道呢; ) 　　现在我们有了ASP.NET Core，这感觉比传统的ASP.NET MVC更自然得多。所谓的自然在这种情况下，意味着和编写传统ASP的感觉几乎相同。这也就是说使用无状态的web工作，而不是试图修复它。使用Request和Response比传统的ASP.NET MVC工作起来更直接，比ASP.NET WebForms甚至就更直接得多。自然并不意味着你必须编写和传统Asp同样非结构化的废话。 ; ) 　　由于我们已经有了非常酷的客户端JavaScript框架。和简化了的、简约的服务器端框架，服务器部分就被减少到仅仅用于在REST服务上提供静态文件和数据。 　　正是这个时候，深入了解TypeScript变得有了意义。但是到这个时间点为止，它对我还没有意义。我用JavaScript编写代码大概有20年时间，但我从来没有在单个项目中写过这么多的JavaScript代码。之后，在过去几年时间里我开始使用AngularJS。Angular2是应该好好研究TypeScript的一个原因，因为现在的Angular2完全是用TypeScript写的。 　　几个星期前，我启动了我第一个真正的NodeJS项目：一个使用NodeJS来为用户提供高度灵活脚本运行时的桌面应用程序。NodeJS提供功能和UI给用户，所有都是用TypeScript写的，而不是普通的JavaScript。为什么?因为TypeScript有很多意想不到的好处： - 　　仍然可以编写JavaScript - 　　帮助编写小的模块和结构化的代码 - 　　帮助编写NodeJS兼容模块 - 　　一般说来，不需要为每个模块写所有的JavaScript代码 - 　　只要专注于所需要编写的功能 　　这就是为什么TypeScript对我来说是个大帮手。当然类型化的语言在很多情况下也是有用的，但是——使用JS工作了20年——我喜欢隐式的类型JavaScript语言的灵活性，并且我对它很熟。这意味着，从我的角度来看，有关TypeScript的优点是，我仍然能用TypeScript编写隐式的类型代码，并利用到JavaScript的灵活性。这就是为什么我说“仍然可以编写JavaScript”的原因。 　　Web技术改变了，我的技术堆栈也改变了，工具也是。所有这些东西都变得更为轻巧，连同工具一起。控制台回来了，IDE变回为它们的root：只不过是一些有着类似语法高亮和智能感知这些作用的文本编辑器。目前，我更喜欢根据我工作的项目类型使用有着“瑞士军刀”之称的Visual Studio Code或Adobe Brackets。两者都开始变得非常快速，包括一些不错的功能。 　　使用轻便的IDE令人愉悦。一切都很快，因为通过我需要开发的app可以使用机器的资源，而不必通过我需要使用来开发app的IDE。这使得发展速度快了很多。 　　现今启动一个IDE意味着启动cmder(Windows上我最喜爱的控制台)，改变项目文件夹，启动控制台命令，从而查看typescript文件，保存后编译。我可以启动另一个控制台来使用如NPM、gulp、typings、dotnet CLI、NodeJS等工具;以及启动我最喜欢的轻量级编辑器来编写代码! : )

　1.没有测试 　　我们很容易毫无原因地掉入这个陷阱。从现在开始，制定计划添加测试到你现在正在处理的代码中，并添加测试到将来的项目中。 　　2.没有从项目一开始就启动测试 　　我们很难再回过头去添加测试，并且可能需要改变架构才能添加测试，这样做最终将需要你花更长的时间才能产出可信任的代码。从一开始就在项目的生命周期添加测试可以节省时间和精力。 　　3.编写失败的测试 　　TDD方法的普及将红—绿—重构的理念带到软件测试世界。这个理念常常被误认为应该“通过编写一个失败的测试开始”。其实并非如此。在写代码之前创建测试的目的是定义系统的正确行为应该是什么。在许多情况下，它是一个失败的测试(红色表示)，但它可能会通过一个非决定性的或未实现的测试来表示。 　　4.担心未实现测试 　　软件开发中的一个大问题就是，代码和任何关于系统实际上应该做什么的文档之间的沟壑。通过拥有一个名称中明确定义你最终想要实现的预期行为的测试，你将从测试中得到一定的价值，即使将怎么写测试目前还不得知。 　　5.没有很好地命名测试 　　命名软件这件事出了名的很难做好，这同样适用于测试。关于如何命名测试有几种流行的约定。无论你使用哪一种都没有关系，只要你能够一贯使用，并准确描述正在测试什么。 　　6.让测试做太多事情 　　又长又复杂的名字通常说明了你想同时测试多件事情。单个测试应该只测试一件事情。如果失败了也应该在代码中注明是什么地方出了错。你没有必要为了知道代码中出了什么问题而查看是哪部分测试失败。这并不意味着你不应该在测试中有多个断言，但这些断言应该紧密相关。例如，一个查看订单处理系统输出，并确认输出中是否有一个单一项目以及它是否包含具体项目的测试，是ok的。但一个验证相同系统的输出的测试，既创建一个特定项目，又记录到数据库中，还发送确认电子邮件，就不行了。 　　7.没有实际测试代码 　　经常可以看到测试新手创建过于复杂的模型以及不能实际测试代码的设置程序。他们可能会验证模拟代码是否正确，或者模拟代码是否和真正代码做相同的事情，或没有任何断言而只是执行代码。这样的“测试”都是白费力气，特别是如果它们的存在只是为了提高代码覆盖率水平的话。 　　8.担心代码覆盖率 　　代码覆盖率的理念很崇高，但往往实际价值有限。知道运行测试的时候有多少代码被执行应该是有用的，但因为它不考虑正在执行代码的测试的质量，因此就变得没有意义。代码覆盖率在它数值非常高或非常低的时候，是挺博人眼球的。如果非常高，就表明，比起带来的价值，过多的代码可能正在被测试。非常低的代码覆盖率表明有可能代码的测试不够。因为这样模棱两可的意思，有的人就不知道单一片段的代码是否应该进行测试。我用一个简单的问题来明确这一点：代码是否包含重大的复杂性?如果包含，那么你需要一些测试。如果没有的话，你就不需要。测试属性访问器不过是浪费时间。如果它们失败的话，那么比起你正在写的代码，你的代码体系出现了一些更根本的问题。如果你不用看一段代码，就立即知道一切，那么它就不重大。这不仅适用于代码，也适用于你写代码。如果我们在任意点重访代码，那么它就需要测试。如果在现有代码中发现过bug，那就说明这一块的代码对其复杂性没有进行充分的测试。 　　9.着眼于一种类型的测试 　　一旦你开始测试，很容易只纠结于一种风格的测试。这是一个错误。只用一种类型的测试，你就不能充分测试系统的所有部分。你需要单元测试来确认代码的各个组件是否能够正确工作。你需要集成测试来确认不同组件是否能够协同工作。你需要自动化UI测试来验证软件是否可以如预期使用。最后，你需要为任何不容易自动化的部分和探索性尝试进行手动测试。 　　10.着眼于短期测试 　　来自于测试的价值大多数会随着时间的推移而获得。测试不应该只存在用于确认事情是否正确写入，而应该随着时间的推移继续起作用，并且对于代码库做其他的改变。有回归错误或新的异常，那么测试应该重复运行以尽早发现问题，这将意味着错误和异常可以更快，更便宜和更容易被修复。没有变化(人为错误)可自动和快速执行的测试，是为什么编码测试如此有价值的原因。 　　11.作为一个开发者，依靠于别人来运行(或编写)测试 　　如果不运行，那么测试几乎没有价值。如果测试不能被运行，那么就可能遗漏bug。自动运行的测试(作为一个持续集成系统的一部分)是一个开始，但项目的任何一个人都应该能够随时运行测试。如果需要特殊设置，机器，权限，或配置来运行测试，那么这些将成为执行测试的壁垒。开发者需要能够在检查代码之前就运行测试，因此他们需要能够访问并有运行所有相关测试的权力。代码和测试应保持在同一个地方，并且所需的任何设置都应该写好脚本。关于这个方面我见过的最坏的例子是一个做的很糟糕的项目，在这个项目中测试人员的子团队定期取走开发人员正在处理的代码副本，他们修改代码以便他们能执行一系列测试，但这些测试是开发人员在特殊配置(无证)的机器上所无法访问的，然后测试人员再发送一个很大的邮件给所有的开发人员以说明他们找到的问题。这不仅是一个坏的测试方式，而且也是团队工作的糟糕方式。不要这样做。代码能够正确执行是专业开发人员的部分属性。要保证代码的准确性，方法是使用伴随它的适当测试。依靠其他人为你写的代码编写测试和运行测试，不会帮助你成为一个专业的开发人员。 　　如果以上这些都不属于你的情况，那么恭喜你!继续保持开发稳健又有价值的软件。 　　如果上面有一些确实发生在你身上，那么是时候做一些改变了。