一切福田,不離方寸,從心而覓,感無不通。

将 Chrome 变成开发利器,开发者们在用这些插件

Chrome 浏览器具有强大的跨平台能力以及丰富的扩展插件,一直是许多开发者的首要选择。而利用许多 Chrome 插件,开发者们在开发流程中能够极大地提高开发效率。我们就整理了十款开发者常用的 Chr Chrome 浏览器具有强大的跨平台能力以及丰富的扩展插件,一直是许多开发者的首要选择。而利用许多 Chrome 插件,开发者们在开发流程中能够极大地提高开发效率。我们就整理了十款开发者常用的 Chrome 插件推荐给大家,相信能够在你的开发中助你一臂之力。 1. 掘金 Chrome 插件:帮你发现干货 不管你是开发者、设计师还是产品经理,想必每天都需要阅读大量的行业相关文章,这就需要我们浏览大量的互联网站点去寻找我们需要的内容。抛开繁复的筛选成本不说,「比特级」的内容都会压得你喘不过气来。 掘金为了解决这个问题,开发了掘金 Chrome 插件,掘金 Chrome 插件聚合了国内外优质的互联网站点内容,在节省你的筛选成本的同时,帮你发现好内容。 2. Postman:强大的 API & HTTP 请求调试工具 相 信 Postman 对于掘金上的各位开发者来说,一定不会陌生,这是一款强大的 API & HTTP 请求调试工具,Postman 不仅可以调试简单的 HTML、CSS 以及脚本等简单的网页基本信息,这款 Chrome 插件甚至还能发送几乎所有的 HTTP 请求,可谓是 Web 开发者的一大利器。 3. BuiltWith Technology Profiler:你的网站,用了什么技术栈? 作为开发者,对于友商网站所使用的技术栈想必也充满了许多好奇心,有没有工具能够帮你完成这项工作呢?答案就是 Chrome 插件 BuiltWith Technology Profiler,它能够帮你分类呈现当前访问网站的技术栈组成,实乃探索友商之利器。 当然,同类产品中,你也可以使用 Wappalyzer 这一款 Chrome 插件。 4. Octotree:你的 GitHub 文档库 GitHub 现有的目录层级形式,在查看来自不同层级文件夹的文件的时候,显得似乎不是很方便,Octotree 这款 Chrome 插件能够让你通过文档库的方式管理、查看你的 GitHub 仓库,简单直观的同时,也方便你进行文件之间的跳转操作。 5. GitHub Awesome Complete:属于 GitHub 的 「Alfred」 在 GitHub 搜索仓库或者项目的时候,你会怎么做?相信大部分人的步骤都是一样的: 在搜索框输入关键字后按回车键 在搜索结果中找到相应结果,点击进入相应页面 有没有更简单快捷的操作方法?答案是 GitHub Awesome Complete 这款 Chrome […]

龙生   01 Jul 2016
View Details

HTML5 实现手机拍照上传

背景:移动端H5项目,需要实现调用手机拍照,并将图片压缩上传功能。 页面样式: 上传图片有原生的方法<input type="file" accept="image/*">,如果只想要拍照上传,不希望用户选择图片上传,可以通过添加capture属性,该属性值有camcorder/microphone/camera…,此处选择camera。PS:该属性存在浏览器兼容性问题,不是所有的浏览器都支持。

  因为原生file样式不满足要求,需要进行相应的处理,此时使用定位,在input上面放置我们想要的页面效果。然后当点击上面的元素,就可以触发我们的input进行图片上传。此时的问题是:当点击input上面的元素,需要事件穿透,即相当于点击input。则借助于css3心术新pointer-events。

  —-此时图片上传的样式已经处理好了—- 代码片段:

  图片压缩处理: 因为要做的是手机拍照上传,现在的手机拍照片都很大,比如小米4S,大小在3M以上,如果原图上传,太消耗用户流量,于是要解决图片压缩的问题。   通过change事件,监听图片上传,通过readerAsDataURL获取上传的图片。

    对上传的图片进行压缩,需要借助于canvas API,调用其中的canvas.toDataURL(type, encoderOptions); 将图片按照一定的压缩比进行压缩,得到base64编码。重点来了:压缩策略:先设置图片的最大宽度 or 最大高度,一般设置其中一个就可以了,因为所有的手机宽高比差别不是很大。然后设置图片的最大size,allowMaxSize,根据图片的实际大小和最大允许大小,设置相应的压缩比率。

  图片上传给服务器: 图片已经压缩完成了,但是压缩后的图片不是File,而是一个base64编码,于是乎两个选择:1、以String的形式将base64编码上传给服务器,服务器转存base64为img图片;2、前端将base64转为File图片类型,上传给服务器。 方法一:压缩之后直接上传base64给后台,实现简单。 方法二:前端自己转存base64位File图片,这个对于前端 压力比较大。原因:html5 canvas属于客户端API,没有权限去保存图片到硬盘,只有canvas.toDataURL()这一接口可导出画布的base64编码,以提供给服务器进行处理保存。所以如果要将base64编码转成图片需要借助于nodeJs。因为nodeJS有相关文件处理的API。

  Summary:如果使用nodeJS,需要单独部署nodeJS代码到服务器,整个逻辑会比较麻烦。综合比较两种方法,推荐使用第一种方法,直接传base64给服务器,后台处理相应的转化! 相关知识科普: 图像一般由两部分组成:一部分是数据本身,他记录了每个像素的颜色值,另一部分是文件头,这里记录着形如图像的宽度,高度等信息。 不同图片类型及适用场景: 不同图片类型: GIF:无损压缩,体积小,支持透明效果,缺点:色彩效果最低,用gif保存鲜艳的图片的话会让网站看上去非常可怕。 PNG:无损压缩,可渐变透明,缺点:不如JPG颜色丰富,同样的图片体积也比JPG略大。 JPG/JPEG:色彩还原性好,可以在照片不明显失真的情况下,大幅度压缩图片格式,所以体积不会很大。缺点:不支持透明 适用场景: 当图片色彩鲜艳,基本没有透明效果的时候,选择jpg/jpeg。 当图片色彩鲜艳,透明效果较多的情况下,选择png; 当图片色彩比较单一情况下,可以选择gif; toDataURL,查找原生压缩图片的方法。type支持image/webp格式

  Base64编码:将三个8Bit的字节转换为四个6Bit的字节。   参考资料: http://www.imys.net/20150916/webapp-input-use-camera.html http://www.oxxostudio.tw/articles/201409/pointer-events.html https://segmentfault.com/a/1190000005364299   from:http://my.oschina.net/zyxchuxin/blog/700381

龙生   01 Jul 2016
View Details

实战:上亿数据如何秒查?

最近在忙着优化集团公司的一个报表。优化完成后,报表查询速度有从半小时以上(甚至查不出)到秒查的质变。从修改SQL查询语句逻辑到决定创建存储过程实现,花了我3天多的时间,在此总结一下,希望对朋友们有帮助。   数据背景 首先,项目是西门子中国在我司实施部署的MES项目,由于项目是在产线上运作(3 years+),数据累积很大。在项目的数据库中,大概上亿条数据的表有5个以上,千万级数据的表10个以上,百万级数据的表,很多… (历史问题,当初实施无人监管,无人监控数据库这块的性能问题。ps:我刚入职不久…) 不多说,直接贴西门子中国的开发人员在我司开发的SSRS报表中的SQL语句:

这个查询语句,实际上通过我的检测和调查,在B/S系统前端已无法查出结果,半小时,一小时 … 。因为我直接在SQL查询分析器查,半小时都没有结果。 (原因是里面对一张上亿级数据表和3张千万级数据表做全表扫描查询) 不由感慨,西门子中国的素质(或者说责任感)就这样? 下面说说我的分析和走的弯路(思维误区),希望对你也有警醒。   探索和误区 首先相关表的索引,没有建全的,把索引给建上。 索引这步完成后,发现情况还是一样,查询速度几乎没有改善。后来想起相关千万级数据以上的表,都还没有建立表分区。于是考虑建立表分区以及数据复制的方案。 这里有必要说明下:我司报表用的是一个专门的数据库服务器,数据从产线订阅而来。就是常说的“读写分离”。 如果直接在原表上建立表分区,你会发现执行表分区的事物会直接死锁。原因是:表分区操作本身会锁表,产线还在推数据过来,这样很容易“阻塞”,“死锁”。 我想好的方案是:建立一个新表(空表),在新表上建好表分区,然后复制数据过来。 正打算这么干。等等!我好像进入了一个严重的误区! 分析: 原SQL语句和业务需求,是对产线的数据做产品以及序列号的追溯,关键是查询条件里没有有规律的"条件"(如日期、编号),贸然做了表分区,在这里几乎没有意义!反而会降低查询性能! 好险!还是一步一步来,先做SQL语句分析。   一、对原SQL语句的分析 1、查询语句的where条件,有大量@var in … or (@var =") 的片段 2、where条件有like '%’+@var+’%' 3、where条件有 case … end 函数 4、多次连接同一表查询,另外使用本身已嵌套的视图表,是不是必须,是否可替代? 5、SQL语句有*号,视图中也有*号出现   二、优化设计 首先是用存储过程改写,好处是设计灵活。 核心思想是:用一个或多个查询条件(查询条件要求至少输入一个)得到临时表,每个查询条件如果查到集合,就更新这张临时表,最后汇总的时候,只需判断这个临时表是否有值。以此类推,可以建立多个临时表,将查询条件汇总。   这样做目前来看至少两点好处: 1、省去了对变量进行 =@var or (@var=")的判断; 2、抛弃sql拼接,提高代码可读性。   再有就是在书写存储过程,这个过程中要注意: 1、尽量想办法使用临时表扫描替代全表扫描; 2、抛弃in和not in语句,使用exists和not exists替代; 3、和客户确认,模糊查询是否有必要,如没有必要,去掉like语句; 4、注意建立适当的,符合场景的索引; 5、踩死 "*" 号; 6、避免在where条件中对字段进行函数操作; 7、对实时性要求不高的报表,允许脏读(with(nolock))。   三、存储过程 如果想参考优化设计片段的详细内容,请参阅SQL代码:

虽然牺牲了代码的可读性,但创造了性能价值。本人水平有限,还请各位不吝赐教! 最后,将SSRS报表替换成此存储过程后,SQL查询分析器是秒查的。B/S前端用时1~2秒!   四、总结 平常的你是否偶尔会因急于完成任务而书写一堆性能极低的SQL语句呢?写出可靠性能的SQL语句不难,难的是习惯。 本文的优化思想很简单,关键点是避免全表扫描 & 注重SQL语句写法 & 索引,另外,如果你查询的表有可能会在查询时段更新,而实际业务需求允许脏读,可加with(nolock)预防查询被更新事物阻塞。 作者:hangwei 出处:http://www.cnblogs.com/hangwei/ 关于作者:专注于微软平台项目的架构设计与开发、数据库调优等工作。如有问题或建议,请多多赐教!   from:http://www.oschina.net/news/74787/how-the-data-on-the-second-search

龙生   01 Jul 2016
View Details