Webpack+Gulp构建开发结构

在浏览各厂的招聘信息时,对“前端工程师”这个词不太习惯,太抬举我们这帮写页面的,甚至觉得有点侮辱“工程师”这词。

因为是外貌协会才入了前端,渐渐地觉得很多东西和之前想的不太一样,比如前端的工程化。

良心好文,建议star: 前端工程——基础篇 by 张云龙

看了这篇文章收益颇丰,加上这两天对构建单页面应用的工作流思考,整合了些轮子,就有了下面这个东西

Webpack-Starter :用以搭建基于gulp和webpack的前端开发环境

页面的View层默认使用React,src文件夹的前端资源整合交给Webpack,所有文件的压缩混淆md5都交给Gulp

下面讲讲这个工作流的思想和实现

前端笔记9.23:AMD与CMD

话说今天在看SeaJS作者玉伯相关的文章时,也搜了一些其他淘系前端大牛。突然看到一个花名:小马。

等等!!好像…好像前几天那位阿里二面时的面试官就叫小马_(:з」∠)_

然后开始了人肉….亲切健谈的面试官竟然是前UED技术负责人,有眼不识泰山的愚蠢的窝Orz

说起来之前阿里的三次面试给人的影响真的挺好,没有大公司架子,而是亲和大气,应该说是和三个人聊了会儿天的感觉。

不过作为前端新人应该过不了吧,还在等结果。


进入正题!这是今天份的前端技能点…

AMD:Asynchronous Module Definition (异步模块定义)
CMD:Common Module Definition (通用模块定义)

说白了只是两个规范,有两个著名的JS分别实现了他们——RequireJS & SeaJS, 虽然都是老物了,下面结合代码做点笔记。

前端笔记9.21:响应式和自适应、触摸事件...

pyQuery

先讲讲这个python包,可以做到类似jquery的功能

1
2
3
4
5
6
7
8
9
# 安装:sudo pip install pyQuery

from pyquery import PyQuery as pq
import urllib2

html = urllib2.urlopen('http://www.wytiny.com').read() #获取html内容
jq = pq(html) #用PyQuery解析
print jq('#id').text()
print jq('.class div.child>ul').find('xxx')

和jquery用法相同,还是挺方便写爬虫抓取信息的。

触摸事件

前天更换了TinyMint的主页UI,仿着写了个全屏滚动jquery插件,也用上了。

但在pad上的触屏滑动并不能带来滚动效果,所以还需要添加一些移动端用的事件绑定,以前没接触过。

React+Webpack

学习各种前端姿势时,感觉前端正处于风起云涌的时代。各种框架、js方言、XXX.js不断涌现,拥有大公司背景的技术也挡不住时代的潮流,或是作古或是推陈出新割据一方。

最近是在逛各种博客,感觉应该接触一些框架或者说设计思想,感受前端的哲学以及技术变迁,而不是赶场凑热闹、把自己束缚在人家设置的条条框框里。

上个星期在看React的内容,很干净的View层。在初学前端的时候感觉分割Html和js是很自然很本能的事,但接触React之后感觉混合也不错,一个个组件很清晰地被组装起来,方便管理。

看了两篇文章,都提到了webpack作为前端资源的管理器。所以我也做了一点尝试,准备用React+Webpack开发一个web应用,用于分享半音阶简谱和歌词。

先贴两篇文章
1. infoQ某文 (代码有小问题,大致内容易懂)
2. 轻松入门React和Webpack

Webpack更详细的资料建议移步webpack cool book
有英文原版和中文翻译。

写下我的开发环境搭建过程:

npm init #略
npm install --save react
npm install -g webpack webpack-dev-server #后者是一个基于express的http开发用服务器
npm install --save-dev jsx-loader css-loader style-loader url-loader file-loader #各种loader是webpack整合资源时使用的工具,还可以添加scss,less等东西
npm install --save-dev react-hot-loader #支持修改文件后自动更新模块,方便开发

webpack的哲学是根据配置文件管理所有的web资源(js代码、js方言代码、模板、图片、样式等),寻找依赖,生成相应的打包文件(pack),高效开发。

Postgres-xl集群搭建

这个星期尝试了postgresql的集群搭建,相比之前的MongoDB,感觉麻烦好多,并且目前也没有成功感觉国内外用PG做集群的好少啊,资料少的可怜

目前查到的有几个方案:GridSQL(已经好长时间没更新),Postgres-XL,pg-pool,plproxy(后两个是备胎)

总体的感觉是PG相关的文档和教程太少,最终选择了XL作为搭建方向,原因是XL的模型和MongoDB的模型很像,容易理解。但搭建的过程中遇到许多问题,很不舒服,主要缺点是不能在一个上层的入口统一管理。

PGXL的模型如下:

  • GTM & GTM_Proxy
    Global Transaction Management全局事务管理
    在顶层负责管理子节点的事务提交和处理,使得整个集群的行为统一,看上去像是一个数据库。
    GTM代理是在有多个GTM实例存在时负责分配的

  • Coordinator(C)
    协调器,Postgres实例,不存储数据,知道所有子节点的位置,是操作数据库的入口。相当于MongoDB中的mongos和config server的结合体。

  • Datanode(D)
    数据节点,实际测试是只读的,不可操作,也是Postgres实例。

按文档的说明,GTM是需要开在独立的服务器上,如果和Coordinator或者Datanode在一起可能会影响均衡。

搭建的时候主要参照了官方文档和下面这篇教程

还算靠谱的教程

VAG 8.5

在上次做完分布式后插入了8000w+数据量做测试。Mongos会调节所有shard,使每个shard有相同的chunk数目,而不是平衡分片的大小。

mongodb分片的条件是片键,片键拥有更高的基数时,分片也会越均匀。最近是用时间作为片键,但问题是,时间的基数虽然很大,但是仍然会有chunk太大无法移动的报错。一个解释是,使用的数据在一段时间内比较集中,制造了jumbo chunk原来是愚蠢的我在插入的时候不下心重复了部分数据…部分chunk翻倍..白折腾一天..Orz

sh.status({verbose:true})

通过上面的命令可以看清楚分片的情况,具体到片键的哪部分区间被存在哪个shard中,这里的一个区间就是一个chunk

经过我的测试,只要超过25w条记录的chunk,就会被标记为jumbo,这类的chunk不能进行分割、移动等操作。

不太明白的是这个jumbo似乎只和量有关,和数据大小似乎没关系。

查询chunk size
use config
db.settings.find({})

比如mongodb默认的chunk size是64mb,看了stackoverflow的一些回答,说是在chunk还未到达限定值的一半时,chunk split已经开始

小的chunk size并不能解决分片不均匀的问题,反而会让chunk split更加困难,特别是在大量值落在同一区间时。

详细查看分片状态
db.collection.getShardDistribution()

在目前的集群中分布如下(有部分重复数据时…Orz)

数据库在空闲时会自动进行均衡,即调整chunk的位置,sh.status()可以看到运行状态,目前主要报错是两种,一种是chunk too big to move, 还有一种是目标分片正在删除chunk无法接受其他分片转移的chunk。目前的数据放在集群里已经两天半,还是在均衡中,chunk移动很缓慢。

查看了下各个副本集,从数据大小来看都保持了同步,记下几个方法:

数据大小查询
db.collection.dataSize() //实际数据大小
db.collection.storageSize() //数据分配到的存储空间大小,并未全部使用
db.collection.totalIndexSize() //索引大小
db.collection.totalSize() //等于storage和totalIndex的和,数据集合实际占用空间大小

查看balance状态
use config
db.locks.find( { _id : “balancer” } ).pretty()
开关balancer
sh.startBalancer();
sh.stopBalancer();


React.js

正在学习….

Mongo Cluster & Sharding

今天尝试了在集群服务器上分片Mongodb数据,做了点mongodb分布式。

Mongodb自带的分布式工具在架设的时候比较方便,要注意的是以下几个概念:

  • Mongod:不同端口运行的mongod是不同的实例,在后台可以看到进程,这是数据分片的基本单位,几个mongod可以搭配成为主从集合或者副本集合(replica set)
  • Config Server:启动时指定了configsvr属性的mongod,和普通mongod不同,这里存有所有数据的信息,即哪部分数据在哪个分片上,相当于数据的路由器。
  • Mongos:数据库入口,本身不存储数据,在启动的时候获取config server信息,和应用程序交互数据。可以指定多个config server作为路由。

为了实现高可靠的大批量数据分布存储,通常会将mongod开在不同的机器上,然后数个机器组成一个副本集合(同个集合中的mongod是存着相同数据的),这个副本集合作为一个分片,数个分片搭配一定数量的configsvr(路由),数个mongos(入口)组成一个分布式集群。

开多个路由是为了提高可靠性,开多个数据入口可以将一些操作分摊到其他机器上,降低负载。(比如一个mongos负责读数据,另一个则负责写)

今天分成了这个样子:
enter image description here

用了6台服务器(性能不同,9/10/11号节点配置稍高一点),7-8-9为一组,10-11-12为一组。

每台服务器上开了一个副本集合,每个含三个副本mongod,Primary(默认主片)服务器的27002端口,其他两个副本片分别位于组内另外两个服务器上。(不把鸡蛋放在同一个篮子里)

这种分法有点像raid….