前端开发调试

前端调试，除了用 console.log，有没有其他办法呢？ Chrome Workspace 调试 可能有的人已经在使用 Chrome 提供的 Sources 功能进行调试了，但是你有没有发现，即使你通过 Chrome 调试发现了问题，你并不能直接在上面进行修改，而是需要切换回你的 IDE 或编辑器去纠正它，非常低效。 对于这样一个出错： 我们点击右边的 index.js?4cba 即可以跳到 Sources 页面，可以看到如下： 但我们没办法直接在这里进行纠正。那有没有办法可以做到我们利用

Redux Model 探索

Dva 的 Model 设计我一直很不喜欢，感觉还是很繁琐，而且经常需要切换文件查看以填写正确的字面量。所以我一直在努力把 Model 进行重写，在不破坏 DVA 本身的前提下。 所以我写了个库 @ali/dva-model，现在还没有开源出来，还在内部测试中。它通过 @Model 装饰器，可以让你用另一种写法来定义 Model，但最终这个 Model 产生的实际还是 Dva 要求的 Model。 下面对比说明下我做了什么改进，后面有几张截图，左边是 Dva Model

使用 CircleCI 实现持续集成和持续部署

最近把一个项目从 Daocloud 迁出，原因是 Daocloud 的企业组需要收费，我们认为没必要付出这笔费用，并且自建的话实际难度不大。 关于 Daocloud，其实我个人很早就不使用了，Daocloud 的 CI/CD 功能我自己使用 CircleCI 来替代，而他的容器管理我则使用了功能更全，对 Swarm Mode 支持更好的 Portainer 替代。 不过基于 CircleCI 我最早也只是实现了持续集成的环节，持续部署这一块并没有实现。但这次迁出的过程中，总算把它给搞定了。 最早的时候也有几种方案，包括使用

Swarm Mode 集群搭建笔记

之前写过一篇博客 在 Docker Swarm Mode 集群使用 Traefik 反向代理。不过这篇文章是我最开始实践的时候的一些个人总结，其实还是有不少问题没解决的。而且写的比较乱。最近我把集群重新搭建了一遍，写下这篇文章，主要是方便以后自己需要的时候查看。一些技术细节本文就不具体说明了，可以自己去搜索了解。 更新内核使用 BBR 不需要可以跳过。使用脚本自动更换，很方便： $ wget --no-check-certificate https://github.com/teddysun/across/raw/master/bbr.sh &

Manjaro Linux 迁移记

使用 Arch Linux 已经有一年多的时间了。最开始的时候为了装 Arch Linux 走了很多弯路，到目前为止，Arch Linux 我应该装的次数有超过十次了，有几次是帮同学装的。在我的带动下，有两个小伙伴也跟我着我用了好长时间的 Arch Linux。 为什么我说我装 Arch Linux 的次数不下十次，是因为我自己中间曾经因为这或那的原因装了其他的，比如因为想玩游戏装回 Windows，因为想换花样装了 OpenSUSE 或者 Ubuntu 或者 Manjaro，因为想换桌面就重装（KDE，GNOME，

利用 ARP 攻击劫持流量并抓包分析 SSR 免流包

本文仅是技术研究，不介绍 SSR 免流方法和过程。而是通过这个分析了解其实现原理。 写这篇文章是因为最近花了点时间玩这个东西，觉得挺有意思的，所以想小结一下，文章内容比较简短～ 我们不妨先抓包看下，经过 SSR 混淆的报文变成啥样子了。 既然我们要抓手机的包，常规做法是电脑配置 HTTP 代理，更改手机 WIFI 代理设置就好了。但是我觉得这样太麻烦，还得拿手机这操作那操作的。。。 我还是习惯简单粗暴的，利用 ARP 直接劫持手机包。当然这个前提是手机和电脑在同一个局域网内。 在 Arch Linux / Manjaro 中，需要先安装这个包：

Routing-Controllers 中自动生成 OpenAPI 3.0 规范文档

在写这篇文章之前，我觉得有必要交代一下前提背景。之前项目我是基于 Node.JS 使用 TypeScript 进行开发，在路由这一块我是使用 routing-controllers 来做的，这个库写起来代码比较易读，该有的都有了，所以一开始觉得没有文档的必要性。每个路由的代码是这样的： /** * 获取新闻列表 */ @Get('/news') async getArticleNewsList(@QueryParams() query: IArticleQuery): Promise<Article[]> { return this.articleService.getArticleNewsList(query)

React 项目架构设计和状态管理方案演进

最近承担了一个项目的独立开发工作，最早还是使用 Redux 来做的，但是后面我改成了用 Mobx 去做。原因其实主要是两点： Mobx 对 TypeScript 支持非常完美，而 Redux 的支持略痛苦。 Mobx 更加灵活简洁，开发更加高效。 这是我目前为止做的最大的一个 React 项目，而且还经历了 Redux 到 Mobx 的重构。这篇文章主要对 React，Redux 以及 Mobx 在项目中使用上发表一些我自己个人的看法。 React

2017 搬砖报告

一年很快就又要过去了，去年年底对 2016 做过一些小结，今年也稍微写点东西吧。这篇文章是自己的一些总结，写出来是自己对这一整年的梳理和记录，没有什么干货。 今年感觉对我而言意义蛮大的，从今年年初考完试之后，大学课程基本就完结了，也就是在今年年初开始去实习。先是在一家小有规模的创业公司实习，实习了半年，主要是 Node.JS 和 Vue 这两块。在 7 月底的时候过去另一家初创公司，主要负责 Node.js，也接触了一下 React Native 的开发，这份实习是比较轻松的，可以远程工作，工作时间也非常弹性。

Redux 异步中间件

上篇博客已经提到了 redux-thunk, redux-promise 和 redux-saga 这三个库. 他们加上 redux-promise-middleware 都是 Redux 异步 Action 的常用的解决方案. 本文就结合其源码来分析他们的异同和优缺点. redux-thunk redux-thunk 是 Redux 作者 Dan 写的中间件. 通过使用该中间件, Redux 支持 dispatch 一个函数(actionCreator), 函数内部可以继续 dispatch. redux-thunk 的源码关键的就这几行: function createThunkMiddleware(

Redux 源码学习

Redux 和 Mobx 是 React 常用的状态管理库. 简单的说, Mobx 是把数据变为可观察, 每个数据在引用的时候都会建立依赖, 当数据变化时, 会去触发依赖高效的进行更新. Redux 则手动管理, 通过 dispatch action 去触发 reducer 变更 state, React 接受新的 state 后更新视图, 一切都自己管理, 所以说是可预测. 我最早接触的 Redux, 不过并没有给我太多好感, 因为感觉写起来太麻烦了, 那时候我还在写 AngularJS,

值得一试的 TypeORM

TypeScript 是一门静态类型语言, 这是我认为的其最大的特点. 在使用 TypeScript 编写的项目中, 应该尽可能使用由 TypeScript 编写的类库或框架. 在传统的使用 JavaScript 编写的 Node.js 后端项目中,比较有名的两个 ORM/ODM 是 Sequelize 和 Mongoose, 但他们对 TypeScript 的支持是很差的, 并不说运行不了, 但是无论是写法还是静态检查上面都很弱. Sequelize/Mongoose 大量使用了对象和函数, 而不是类. 举个例子, 在

在 Docker Swarm Mode 集群使用 Traefik 反向代理

2018.3.30：我写了一篇类似的文章，解决了这篇文章部署过程中的一些问题，建议直接阅读 Swarm Mode 集群搭建笔记 。 最近在两台服务器上部署 Docker Swarm Mode 集群. 整整花了三天时间才搞定. 最终的技术方案是 Docker Swarm + Convoy + Traefik + Portainer. 简单总结下过程. 安装 Docker 和 Docker Compose Docker 这里推荐两种安装方式, 一种参照 https://docs.docker.

十月杂谈

最近把自己的一些项目整理了下, 该丢的丢, 该优化的优化, 该调整的调整. 换了一个新服务器, 旧的服务器打算用来搭游戏服用. 原来的服务器其实跑了很多我自己的一些个人项目, 不过由于种种原因不想迁移过来了. 一个是书籍购买的网站, 丢掉的原因是运行不起来... 因为当初那个项目后端没有对依赖进行锁定, 导致后面重新安装的时候, 运行的时候就报错了... 如果是 node 的话还好, 关键后端是 python, 修起来估计不简单. 遂抛弃. 还有一个是 RSS 订阅器, 丢掉的原因是这货太占空间... 因为它每天都要去抓取一堆文章写到数据库... 加之我现在已经不怎么用了. 而且这个项目一开始并不是跑在 Docker 上面, 而是用 PM2 运行. 改起来也不是很方便.

关于 Node.js 测试

单元测试是大型 Web 项目必不可少的部分. 测试和其他部分一样, 从一开始就要设计好实现, 否则可能就可能不断给自己买埋坑. Node.js 的测试一般由测试框架和断言库两部分组成. 测试框架用的比较多的是 mocha, 我也用过一阵子的 ava. mocha 大家可能都比较熟悉, ava 可能实际使用的不多. 这两个其实差别也有点大, ava 的话是每个文件都开一个进程执行, 并且文件内的测试默认是并发执行, 听起来就很快. ava 的写法也比 mocha 简洁很多. ava 自带断言库, 并且支持异步断言(assert 通过插件也可以实现, 但没有 ava

Vue 双向绑定原理

以前写 AngularJS 的时候曾经分析过其双向绑定脏检查机制, 转向 Vue 开发也挺久了但一直没有去研究其源码, 也就前段时间去研究下了其 nextTick 的实现. 今天主要看了 Vue 双向绑定的机制, 感觉 Vue 的代码比起 AngularJS 要容易看很多了, 不过东西也挺多的, 代码质量不错, 写篇文章巩固下. 源码分析 Vue 实现双向绑定有一个非常重要的方法就是 defineReactive, 搞懂这个方法对理解 Vue 的双向绑定帮助非常大. 文章源码篇幅比较多, 但其实代码并不难理解. defineReactive 大致过程如下: (注: 结合我看的最新的源码,

高并发下的抽奖机设计实现

最近在公司负责一个营销系统的后端实现. 其中有一部分就是涉及到抽奖机. 为了尽可能让抽奖机能容纳更大流量的瞬时访问, 减少不必要的开销, 同时让抽奖机具备一定的可扩展性, 我花了很多时间去想着改进它. 总结下在这个抽奖机中的一些经验. 如何判断活动是否已经开始或者已经结束? 活动有一个开始时间和结束时间. 当用户参与一个活动的时候, 每次从数据库查询出活动时间和结束时间然后和当前时间比对这样显然是可以的. 但是由于我们并不能确定用户请求该接口的时机, 所以每次都要去查询. 这样带来的开销就比较大, 况且你还要考虑如果是一个秒杀活动, 高流量下你还要每个访问都查询数据库就显得不实际了. 因此我们可以考虑存放缓存. 当活动创建时, 保存活动时间到缓存. async setActivityIdLifeCycle (activityId: number, startAt: string, endAt: string): Promise<void> { await Promise.

使用 TypeScript 开发后端应用

大多数人接触 TypeScript 开发会遇到的一个问题就是很多原先使用的库都是用 JavaScript 写的. 虽然在 TypeScript 项目中也可以使用他们, 但是有些库的用法还是面向过程形式的, 就和我们在 TypeScript 中用面向对象的写法有点格格不入. 有些库由于比较小众可能不存在声明定义文件, 这就导致了编辑器没法进行静态类型检查. 使用 TypeScript 应该抛弃原型链, 尽可能多的使用面向对象的方式来编程. 尽可能多的使用装饰器. 如果这么做显然就和我们传统的使用 JavaScript 编程有了差异. 那么, 怎样优雅的使用 TypeScript 呢? TypeScript 生态不乏很多优秀的库, 例如关系型数据库 TypeORM, 依赖注入 inverisifyJS 和