标签 node.js 下的文章

Eggjs 从放弃到开始使用

咦,这篇文章标题为什么反了?

实际上这是个人走过的心路历程,最初看到 eggjs 的时候,我就觉得 Egg 很明显不符合我的审美——我选择 koa 的理由就是小巧精致,all in middleware. 而 eggjs 不是画蛇添足吗?

这次新项目用到了公司自改版 egg,不过其实也就是 egg 多封装了几个 service。

——一开始我是拒绝的。

- 阅读剩余部分 -

MIME 与 Nodejs 的小故事

之前同学问了我一个问题,他用 Java 写的客户端并发出的请求在 Java 的服务端可以接收,他想改成 Node.js 的服务端,但是就遇到了没法正确处理的问题。

经过 Header 的查看,首先我们发现了 Header 中没有 content-type,最初我的思考角度在于 content-type 没有的情况下,会不会存在 Java 服务端的默认值而 Node.js 的服务器并没有处理。由于他说传的是二进制文件,想当然的想到了 multipart/form-data,但是对于 multipart 而言,应该是有特殊首部要求的,明显不满足这个条件。

- 阅读剩余部分 -

Node.js 快速开发 cli 应用攻略 - 坑篇

「哇夭寿拉,文章都按照上下章来写啦」

因为一直找不到时间写,上次匆匆做完了介绍,所以开个下集谈谈几个库遇到的坑。

commander

commander 的 bug 确实挺多的,所以下一个坑准备试试 yargs 这个库(差点就准备自己写了 OTZ)。

argument 'domain' (and probably others) cause naming collision

- 阅读剩余部分 -

Node.js 异步原理

写文章写得实在生无可恋,依旧看起了书——《深入浅出 Node.js》,觉得自己确实有错,之后如果有人问我 Node.js 入门怎么入门我可能还是会推荐他网上的教程,但是说到推荐书,这确实是一本很棒的书。

——安利完毕,之后进入正题。

在面试时可能真的会遇到这样的情况,面试官问:请问一下异步是怎么实现的。

之前在听小伙伴说到这个问题的时候一脸黑人问号,毕竟仿佛是一知半解,不得其意,今天总算可以好好聊一聊异步了,也算是一个章节的笔记。不过掌握的还不是很透彻,如果有错误请指出。

- 阅读剩余部分 -

使用 Swagger Mock API

Swagger 是一个完整的从设计到文档到 Mock 的 API 生态体系。

它会帮助你进行一定的设计,对于不符合的设计会报错,你需要掌握它的 yaml 文件书写规范,可以通过 OpenAPI Specification 稍作了解。

最初写文档可能会因为 yaml 语法不熟报一堆 error,习惯之后基本上也没啥问题,这样可以摒弃一些不规范的文档带来的沟通成本。

当然,今天就不介绍这一部分的信息了,在http://editor.swagger.io/#/会存在默认的示例。

- 阅读剩余部分 -

WangTrans 开发手记

WangTrans,汪星语翻译机开发其实已经一个多月了,也就是在半天里消极怠工写的东西,尽管依旧no star,不过发布在npm之后竟然也有莫名其妙的下载量,当晚就想总结一下学到的一些东西,但是由于每天回家都是——好累,不想动的循环,所以就拖到了现在。

想法的来源是因为单身狗每次都要手动输入汪汪汪+拼音,在虐狗节就非常的麻烦!说干就干……所以这是个非常标准的玩具。

第一段废话完:https://github.com/csvwolf/WangTrans

- 阅读剩余部分 -

说说Promise

标题不知道怎么拟定比较好,总之是讲Promise的吧,基本上算是第一次讲Promise,以前Rails+Angular的时候曾经说过,不过那个时候对于callback hell和Promise解决的东西理解的并不深刻,所以解释的也很肤浅(不明明这次依旧是肤浅的解释)。

首先……V8的Promise性能实在不靠谱,都没有第三方的快,bluebird有一篇性能比较(反正大致是想说自己快吧):http://bluebirdjs.com/docs/benchmarks.html

慢归慢,基本上一些对于性能需求不太迫切的项目还是可以用自带的Promise的,Node6对于ES6的支持已经相当全面了,这一点可以用npm install es-checker检查一下。(毕竟回调地狱恶心到吐血)。

- 阅读剩余部分 -

Node.js 用Mocha+Chai做单元测试 入门

昨天是六一儿童节(发布的时候已经是前天了= =),给自己放了一天假,然后晚上开始看自动测试的问题。

单元测试是每个程序员都应该自测的部分(《构建之法》中说:单元测试应该由最熟悉程序的人来写——也就是些这段代码的程序员)传统的测试机械化程度太高,肉眼看也是累得不行,此外,代码覆盖率是一个很重要的考察点,人工测试在计算上或称最大难题。

基本概念

当然在此之前,先来科普一些基本概念,也就是单元测试的分类:TDDBDD

- 阅读剩余部分 -