enjoy coding

we may not make events,but when we try,we learn.

Note of Great Blog

| Comments

连续性的做一些事情

Google SEO 工程师 Mutt Cutts 提出过一种很好的实践方法(TED2011):Try something new for 30 days。偶尔的一次尝试只是为生活平添了几分色彩,但是如果一直做下去,30 days × N 后,你的生活就会发生改变。

Bio

我在学校的时候掌握了电路。

通过自学我掌握了算法之“道”。

不过我发现它们是错误的“道路”。它们的追随者只了解技术之“阳”并且对代码顶礼膜拜。但技术是没有灵魂的,代码没有道德可言。于是我陷入了绝望。

于是我开始寻找新的道路。终于在多个漫长的年头之后,我发现了设计之“阴”,它讲的不是东西,而是人,我开始学习如何根据人的感知和理解来设计界面。

等到我掌握了它,仍旧发现它是错误的“道路”。它的追随者只学会了如何回答问题,但从来不去质疑这些问题。于是我再一次陷入了绝望。

我又开始寻找和思考,并且开始走自己的道路。终于有一天,我悟道了。

真理之路凌驾于任何琐碎的技能之上。这世上并没有所谓的“技术”,也没有所谓的“设计”,只有一个人应该成为什么样的人,以及在这个过程中保持一颗不屈的决心。其他的只是细节。

这就是我的教学方式。

Note of Mqtt Protocol

| Comments

blog

1
2
- [SSL/TLS配置(证书生成需要注意CN不能乱填)][1]
- [mqtt协议详解][2]

JPush参考发现的一些点:

1
2
3
4
5
6
- 推送信息的保存时间长短(10天?)
- 单设备多用户
    - server端记录设备的id,多用户通过别名其它机制来做逻辑的映射
    - 但极光的做法是单个设备和别名一对一,不同用户登录,别名会被覆盖
    - 提供有限时长过的记录保存
- [极光推送的很多策略值得参考,API设计的也不错][3]

Note of Learning Skills

| Comments

关于学习的摘抄

You don’t need to learn everything, you just need to be curious about learning. When the time comes that you need it, you’ll be prepared.

便于记忆的集中方法

1
2
3
4
5
6
7
8
9
10
11
12
- 把长时间的学习分割为几个单位,使“最后”和“最先”的情况大大增加,理想的学习时段是10分钟到45分钟,中间休息时间2-10分钟。
-  运用连锁关系和出色醒目。即编造本不相干的A、B关系,使其练习起来。然后把A、B夸大,使其变得荒唐或者幽默,而且尽可能想象自己触碰到它的外形,听见它的声音,看见它的画面,闻到它的气味等等。

- 每天,去观察人的某个特定部位,多多观察其特异性,就比较容易记住自己所遇见的新面孔。

- 学习一个时段后休息大约10分钟,然后首次复习,隔一天再进行第二次复习,1周以后第三次复习,1个月以后第四次,4个月后第五次复习。

- 用关键字句,特殊的画图记日记。

- 有意识地反复回忆一些事情。

- 经常在脑中展现生动形象,色彩丰富的画面,这样能训练右脑的思维。

Reading Note of About Face 3

| Comments

定义交互框架

1
2
3
4
5
6
7
8
9
10
11
12
13
- 定义外形因素、姿态和输入方法

- 定义功能和数据元素

- 决定功能组和层次

- 勾画出大致的交互框架

- 构建关系线路场景和剧本

- 通过验证性的场景剧本来检查设计

- 形式(工业设计师、图形设计师)+ 内容(信息架构师、文字编写人、动画制作师) + 行为(交互设计师)

Reading Note of Mosquitto

| Comments

背景

之前在游戏公司的时候,需要自己搭建一套推送服务,顺道研究了下一些开源实现。mosquito的代码库,代码量少,而且也写得比较好懂,对推送协议的实现也是比较ok的,所以就撸了一番。虽然后来没用上,但是还是把当时的一些想法记录下来。

缺点

1
2
3
4
5
6
7
- 基于poll的事件模型,没有epoll的性能好
- 内存分配策略简单,来一个生成一个,存在优化空间
    - 比如改用初始2倍,到达一定数量后,以后每次改用增加额定数量的算法
- 数据结构过于简单
    - 常用结构为单向链表,查找耗时为O(n),存在性能问题
- 内存占用过大
    - 没有使用数据库,数据都堆在内存里面,可能无法应付大数据量

Sharding of Mongodb

| Comments

blog教程

分片概念

集合可以被分片,一个片可以包含多个区间,一个区间可以包含多个块,一个块可以定大小.所有这些概念都是逻辑上的,真实的物理存储并不存在这样的一一对应关系.如下图:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 分片1----
           |
           |
       +++++++++++
       +  |------ 块1   +     区间1
       +  |------ 块2   +
       +++++++++++
           |
           |
       +++++++++++
       +  |------ 块3   +     区间2
       +  |------ 块4   +
       +++++++++++
           |
           |
       +++++++++++
       +  |------ 块5   +     区间3
       +  |------ 块6   +
       +++++++++++

      逻辑概念与物理概念上并不一致

Reading Note of the Totor Library for Python

| Comments

背景

在ziz的时候,cto的技术选型不合理,对使用技术缺乏必要的了解,采用了旧和大而笨重的中间件。因为tcelery的核心开发者不再维护代码,所以需要重新选择更加合适的技术方案。

阅读

原版的tcelery有几点问题:

1
2
3
- 对于redis的backend,存在race condition的情况,具体要参考下[git issue][1]
- 对于超时的处理,如果worker跑这个任务运行的运行时间超过规定时间,客户端的连接就会卡死
- 代码时间有点旧了,作者mher也没有继续维护和做codereview的工作

后来认识了一个提交pull request的童鞋,因为作者没有维护采纳修改的缘故,他做了一版新的工具,totoro。现在的项目就是基于这个来开发的。

ps: segmentfault有专门一个问题来讨论这个bug的,也可以去看看解决方案(其实是我自问自答啦)。