分类目录归档:thinking

express请求流中的错误捕捉处理

nodejs中的错误处理还是比较麻烦的,尤其遇到异步回调之类,多层嵌套,简单的try…catch无法处理。

目前在用expressjs,拿此举例说说怎样实践。
第一种,从一介布衣那儿看到的方法,可行:

const domain = require('domain');
app.use((req, res, next) => {
  const reqDomain = domain.create();
  // next抛出的异常在这里被捕获,触发此事件
  reqDomain.on('error', e => {
    // ... 这里统一处理错误,比如渲染或跳转到404,500页面
  });

  return reqDomain.run(next);
});

通过在route定义之前添加如上的中间件,可以捕捉到大部分的错误。

第二种,上面说到是大部分的错误,因为我碰到了一个没成功捕捉到的,就是使用swig模板渲染时的变量报错。

// 设置模板引擎
app.engine('swig', swig.renderFile);
app.set('view engine', 'swig');
app.set('views', `${__dirname}/views`);
app.set('viewExt', '.swig');
// 在某处渲染输出: 
res.render('template/filepath');
// 如果在filepath.swig文件中有变量报错,则第一种方法不能成功捕捉

这时在stackoverflow找到一个方法,

// 依然按第一种方法写错误捕捉
// 然后在route之后再写个中间件

// 最后的错误处理,比如发生在res.render中的错误
// 由于已经设置了响应,因此只能发送状态码,或跳转
// next不能去除,否则无法获取到错误
app.use((err, req, res, next) => {
  // res.sendStatus(500);
  log.error(err);
  // res.redirect(301, '/'); // 跳转到首页
  next();
});

ok,经过验证,上述方法已经能够处理目前所有遇到的问题。

第三种,为什么会有这一种方法呢,纯属个人思维发散,由于是express内部处理了模板引擎,导致res.render方法不能正常抛出错误被外围捕捉,那么我直接用swig方法渲染文件,并把渲染后的结果通过res.send方法响应是不是可以呢?

// 之前是这样渲染的
res.render('template/filepath');
// 改为
res.send(swig.renderFile('/...这里应该是物理绝对路径.../template/filepath.swig'));

经过上面改造,发现只用第一种方法也可以正常捕捉到错误,说明推论正确。

之所以在第二种还能解决的情况下还在寻找其他方案,是因为第二种的最终错误处理只能响应状态码,而不能再渲染页面了。终究不够完美,方法不够优雅。

像第三种方式,完全可以不必设置express的模板引擎了,用res.send + 模板自身的渲染方法即可,封装为一个方法,方便调用。

慢速度才显示loading

Loading提示应该是广泛也普通的应用了,其意义都明白。

这里我想说的是,在资源载入速度很快的情境下,loading提示往往一闪而过,所以其实是没必要显示loading的。这应该是可以优化的一个点。

如何优化呢?假设提供loading的两个方法:loading() 和 loaded(),只需loading设置一个比较理想延迟的setTimeout,loaded里面清除timeoutId即可。

Full-WebSocket网站应用思路

这几天一直在想的事儿,曾经也有这样的念头一闪而过:全站基于WebSocket的网站应用。

首先是前后端分离的开发模式,借用REST的api做数据交互,那么如果根本不用rest api,而是页面一旦打开就建立一个WebSocket,页面数据的产生和更新全通过socket连接而不是ajax,前后端就完全基于scoket事件来开发,尤其对于Single-Page-App来说, 都用不着angular.js这样的MVVM框架。

比如 UI-1, UI-2…UI-n等共同使用到一条数据data,当data在任意UI上发生了改变并传回了后端,后端处理后更新数据回推到前端,前端基于scoket事件的机制,可以自动响应这一事件的UI更新操作,UI-1,UI-2,UI-3都可以及时得到渲染更新。

socket可以做到单独数据块的传输,细分数据,前端组合数据或可以“逐行”更新界面,BigPipe。

这种开发模式还存在一些待定的问题,比如长期打开一个连接对后端是怎样的一个压力,相比较普通开发模式(大量短期连接)有没有优势。

不知道这种模式是否已经存在于现有网站应用上。当然游戏界应该是有的了,我只是想网站开发也这样呢?

网页设觉设计师,你做好准备了吗

网页的视觉设计,个人认为必须要考虑到的因素: 一是视觉,二是交互。

纯视觉,无需多言。有些却必须考虑到交互。说到交互,拿最常见的select举例。
select是css无法过多控制ui表现的标签之一。

实现一个被设计的很好看的select功能的组件: 一是js替换原生select标签,生成html模仿。二是纯html模仿select,不写select标签。

再看看原生select有什么可能操作,首先原生事件onchange,onfocus, onblur,其次互相联动的一组select,再者还有原生属性multiple,size,disabled等,最后select不是孤单的,它还有配套的子元素option,option的操作可能有 增减option项目,诸多原生事件onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup,原生属性selected,disabled等。

这些操作或属性等用原生select很好实现。但是如果设计给一个很好看的下拉ui,就需要用上述所说的两种实现方式选1个来实现。

那么实现出来,还必须能够有原生select会有的操作。成本:

1、ui实现成本。2、原生js事件模仿响应成本。3、交互实现成本。4、手持设备适应。5、对新员工培训使用成本。6、各种未预料情况的修订成本,比如tab控制表单元素切换。

是不是每个项目都有一套不同的ui?那么实现多次?

视觉设计并不仅仅是视觉感官,放到网页设计中来,就需要考虑到交互因素,而且是很重要的因素。
网页设计不是平面设计,涉及交互可以算是一大区别。

单一功能型ui,还是表单密集型ui,单一交互ui,还是复杂交互ui。哪个适合定制设计,哪个适合原生元素,考虑清楚再做设计,要抛弃所谓的UI设计唯我独尊。

只要是项目中的一员,都应该对项目做出考虑,尤其设计属于一个产品靠前的一个步骤。为表单密集或交互复杂的功能去设计一套为了好看和统一的ui,将影响整个项目的进度和实施,增加很多成本。

 援引一句话(http://bbs.meizu.com/viewthread.php?tid=3875466):

在做flyme1.0的时候,我们曾因为顶部条的配色问题改过很多很多个方案,我们一个小改动都是需要花很多时间去跟进后续的东西(比如交互方案,视觉效果等等),但的确我们还是因为想琢磨出满意的方案而折腾了很多很多天。

网页视觉设计师,你做好准备了吗?

淘宝虚拟物品买卖自动化的解决方案

小盆友“菜熊”童鞋最近开了个淘宝店,卖虚拟物品:教育视频。他现在是纯人工操作,有人买就咨询联系他,买了后旺旺发给买家下载链接。这样需要他看着店,不能自动化,不能有效解放人工。

刚刚在刷牙(现在是晚上23点),突然想起他这个事情了,又突然想起淘宝开放的API,然后突然想起一个自动化解决方案,此前本人对这个没什么了解和研究的,是一时兴起。提起115网盘,各位大概就明白了。

首先, “菜熊”童鞋需要一个服务器,存放视频文件。其次,需要开发一个前端下载控制系统,开发一个淘宝API同步系统。 Continue reading 淘宝虚拟物品买卖自动化的解决方案

Google JavaScript 编码规范指南

来源于: http://www.chuan.shanghuo.net/wordpress/?page_id=233

Google官方文档地址(English): http://code.google.com/p/google-styleguide/

淘宝总结的: http://docs.kissyui.com/

Google JavaScript 编码规范指南

 

修订版: 2.9

Aaron Whyte 

Bob Jervis

Dan Pupius

Eric Arvidsson

Fritz Schneider

Robby Walker

每个条目都有概述信息, 点击

查看详细的内容.

你也可以点击下面的按钮

 

展开全部

重要注意事项

显示被隐藏的内容

link 

 

这份指南中, 可以点击旁边的按钮来显示更多的细节.

Hooray! 这里是更多详细的内容, 你也可以点击最上面的”显示/隐藏全部按钮”来切换显示更多内容.

Continue reading Google JavaScript 编码规范指南

Google用户体验设计的10准则

来源于: http://howe.im/网络/google用户体验设计的10准则.html

Google的愿景

Googl用户体验团队致力于创建有用的(useful)、快速的(fast)、简单的(simple)、有吸引力的(engaging)、创新的( innovative)、适合大众的(universal)、有用的(profitable)、漂亮的(beautiful)、值得信赖的(trustworthy)、个性化的(personable)的应用。

Google用户体验的十大准则

1.将焦点集中在用户的生活,工作,和他们的梦想上。

Google 用户体验小组努力发现用户的真正需求,包括那些他们自己都无法阐明的需求。有了这些信息,Google 就可以创建解决现实问题的产品并激发所有人的创造力。Google的目标不仅仅是按部就班的工作,而是改善人们的生活。总之,一个精心设计的 Google 产品在日常生活中是非常有用的。他并不是靠花哨的视觉效果和技术打动用户的,虽然也有具备这些特性。他不会强迫用户去使用他们不想要的特性,但是他会引导有兴趣的用户自发的去使用他们。他不会入侵别人的生活,但是回想那些想要探索世界信息、工作的更加快速和便捷、分享想法的用户敞开大门。

Continue reading Google用户体验设计的10准则