spider related

怎么部署

  • scrapyd + supervisord + crontab + redis

可以用的一些 lib

分布式

参考的 blog

入门

结合

行业资料

行业需求

  • [lagou]

其他

比如如何防止被 ban 掉

Here are some tips to keep in mind when dealing with these kinds of sites:
- rotate your user agent from a pool of well-known ones from browsers (google around to get a list of them)
- disable cookies (see COOKIES_ENABLED) as some sites may use cookies to spot bot behaviour
- use download delays (2 or higher). See DOWNLOAD_DELAY setting.- if possible, use Google cache to fetch pages, instead of hitting the sites directly
- use a pool of rotating IPs. For example, the free Tor project or paid services like ProxyMesh
- use a highly distributed downloader that circumvents bans internally, so you can just focus on parsing clean pages. One example of such downloaders is Crawlera

reading note of the totor library for python

背景

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

阅读

原版的 tcelery 有几点问题:

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

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

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

how to do product analysis

基础框架(待修改)

  • 背景
  • 竞品对象
  • 竞品分析
    • 定位和功能(战略层)
      • 产品定位(包括目标人群等)
      • 产品功能
    • 用户需求
    • 设计和技术
      • 交互和体验
      • 视觉和风格
      • 亮点功能和核心技术
    • 运营及商业化
      • 运营模式
      • 盈利模式
    • 市场推广
    • 用户数据
      • 用户数量和活跃度
      • 转化率、健康度
      • 在线时长
      • 地域差异
    • 策略
      • 版本迭代和演变
      • 公司战略
    • 优缺点总结和借鉴
  • 总结

一些技巧

  • SWOT 分析方法
    • Strengths(竞争优势)
    • Weakness(竞争劣势)
    • Opportunity(机会)
    • Threats(威胁)
  • $APPLES 分析方法
    • 方法简介:每个字符代表一个维度,每个维度有一定的权重,针对每个竞品从各个维度按 1-10 进行打分,每个得分乘以对应权重然后求和,得出该产品的总分,最后对每个产品的总分进行对比分析
    • $:价格
    • A:可获得性
    • P:包装
    • P:性能
    • E:可用性
    • A:保障
    • L:生命周期
    • S:社会接受度
  • 分层分析方法(Analytic Hierarchy Process,简称 AHP)
  • 价值曲线分析法 (把对方的功能点列出来,通过打分来确定对方的优劣,以及发现哪些可以尝试突破的点)

the reading note of web page design

背景

接触 web 最开始的时候,是做重构,那个时候便想着一定要学下网页设计,于是就找了下面这本书。

reading notes

作者是一个叫 jason Beaird 的外国友人写的,非常的薄,但胜在把一些纲领都列了出来。

内容结构

  • 版面设计与构成
  • 色彩(颜色搭配)
    • 单色搭配
    • 相似色搭配
    • 补色搭配
    • 美异补色、三阶色、四阶色
  • 材质
    • 线
    • 图案
    • 广度和深度
    • 风格
    • 排版
    • 字体
    • 标点、符号
  • 修饰
    • 照片库

the methodology of startup

市场调研的框架

创业者要做的事儿,说简单也简单,说不容易也不容易:

  • 要深入研究自己所处的领域;(大多数人只不过以为自己了解自己所处的领域……)
  • 要多研究几个自己可能理解的领域(其实不能、也不应该,只局限于自己曾经熟悉的那个领域中);
  • 给所研究的领域画出一个图谱;看看什么有人做、什么没人做、什么人做得好、什么人做的不好,为什么?
  • 深入分析自己的状态;
  • 选择合适的领域,在那个领域里画出自己的活动范围;
  • 设置可能的目标。

方法体系

那些常常审视自己思考质量的人,都会很认真地定义自己所使用的概念:

  • 这个概念有必要存在吗?
  • 它指的究竟是什么?
  • 反过来,它所指的究竟不是什么?
  • 它与什么类似?但有什么不同?
  • 使用它的时候要注意什么?
  • 用错的时候可能产生什么样的后果?

如何实践最重要的概念

再进一步,其实总共可以问两个问题:

  • 什么是最重要的概念(以及相关的方法论)?
  • 这个概念(以及相关的方法论)还可以用到什么地方?

解决问题

正确的方法论可能是这样:

  • 一方面,专注于自己的进步,让自己成为能解决更多问题、更大问题的人 —— 只要时间足够久,进步是一定的;
  • 把自己能解决的问题,都给解决了,为了自己,也为了别人。
  • 另一方面,在自己的能力范围内,尽量帮助那些可能解决很大问题的人。但必须牢记,解决那些问题,可能并不是此人的责任,也不一定是此人能有的运气。

很多的时候,就是这样,所谓的 “平和” 只不过是认真思考的结果。

说服他人的终极技巧

所以说,说服他人的终极技巧,是这样的:

种下种子,坚决不提结论,让他自己想。

YC 创业课思考方法

  • 第一课 创业点子、产品、团队和执行 & 我们为什么要创业
  • 第二课 创业点子、产品、团队和执行
  • 第三课 创业中违反直觉的地方,以及如何获得好的创业点子
  • 第四课 做产品,和用户交流,然后成长
  • 第五课 商业策略和垄断理论
  • 第六课 增长
  • 第七课 如何做出用户喜欢的产品
  • 第八课 从小事做起 & 创业公司的公共关系 & 如何启动
  • 第九课 如何融资
  • 第十课 公司文化和团队建设
  • 第十一课 公司文化和团队建设 2
  • 第十二课 如何做企业级产品
  • 第十三课 如何做一个优秀的创始人
  • 第十四课 如何运营公司
  • 第十五课 如何管理
  • 第十六课 如何做用户调研
  • 第十七课 如何做硬件产品
  • 第十八课 法律与财务基础
  • 第十九课 销售和市场、如何与投资人交谈、如何安排与投资人的会面
  • 第二十课 最后的建议

阅读列表

gentoo related stuff

背景

接触编程的那段启蒙的日子,有玩过 gentoo,一个给你材料让你自由发挥的小玩物,不过后来折腾不起,逐渐就放掉了。
笔记里面还有之前整理的一些资料,都放出来吧~

编译笔记

开发部署

note of optimization for zdlive web sites

前言

zdlive 是我大四实习的一家公司,当时在那边负责前端模块,写了蛮多的笔记,现在整理出来~=)

相比起后台的优化,前台的优化一般都会被忽视,但其实在用户发起一个页面请求,到页面最终展现给用户,前端所占的比重是非常大的。看了《高性能网站建设指南》,还有《构建高性能 Web 站点》的部分章节,针对 zdlive 的页面,可以做如下优化尝试。

优化的指导方针共有 13 条,结合 zdlive 讲。

减少 HTTP 请求

一般我们的网页会有如下三种,图片、css 文件、js 文件和 html 文件。当用户在输入输入网址的时候,浏览器会向服务端发起一个 http 请求。当这个 html 文件被下载到客户端之后,其他的组件才开始下载,我们以 zdlive.com 为例。

可以看到,所有的组件下载,都是等到第一个文件载入完毕后再发起的,而这里的每一项都是代表着一个 http 请求。

对于一个页面来说,多个 http 头并没有什么关系,但对于响应速度和稳定性要求高的,比如 zdlive 的首页,尤其是 gprs 这样坑爹的网络下,多个 http 头,意味着速度慢,请求失败的几率会很大,页面显示不完整等等问题。

那我们要做的就是减少 http 请求了。

方法有如下几种:

  • 减少图片。目前比较常见的做法是把多张图片整合到一张图片里面,然后利用 css 的技术,比如 background 的定位来做到共享图片的目的,这种技术叫做 CSS Sprites。  坏处有 2,定位麻烦和单张图片的大小会很大,这样用户请求到完成的时间就会比单张小图片要久。

对于我们的首页来说,这种做法还需要实际测试下。

  • 内联图片。对图片进行 base64 位的编码,这样图片就可以和 html 文档一起下载到客户端了。

坏处是 Base64 位压缩以后,图片的大小会变大。但结合服务端的 gzip 压缩,减少客户端的 8 个请求,还是可以尝试下的。

  • 合并脚本和样式表。

对于一个文件来说,通常会有多个脚本文件和样式文件,分开是模块管理的需要,但有时候也可以结合在一起,合并下载。但这个单个文件大小,和多个 http 请求头之间的怎么去权衡,我还不是很清楚。 ## 使用内容分发网络 内容分发网络的意思是说,假设我们公司现在有多台服务器,一些专门用来跑应用支持,一些专门用来给用户下载文件的,比如 img 文件、mp3 文件等等。而这里,内容分发网络就是指这些用来下载的服务器了。只是,他们现在都在北京这个地方,如果这些被用户用来下载文件的服务器能部署在全国各地,那对于用户来说,更近的服务器,就意味着更短的相应时间和更快的下载速度。

拿 douban 的豆瓣 FM 来说,当我发起访问的时候,实际上我听的歌曲并不是在北京那边的服务器给过来的,倒是从广州这边的服务器下载的。

具体测试,可以用下抓包工具查看 ip 地址信息,海富推荐用 fiddler2。

继续阅读

no silver bullet

背景

研究测试开发相关资料做的一些总结,备用~

文章

从 rails 身上学测试

  • 系列文章
  • 单元测试针对 model,按理不应该包含数据库操作,只是测试 model 的业务逻辑,验证规则之类的。
  • 功能测试,rails 的是针对单个 controller,测试 action 用的,这个肯定需要配合数据库。
  • 集成测试用来测试多个 controller 的协同工作,主要测试工作流程,业务流程。一个流程会涉及多个 controller,肯定需要数据库的配合。
    • 集成测试,可以定期做,也可以经常性的做。
    • 其实测试的主要作用的验证系统,验证代码,是否满足需求。
    • 如果代码有变更,系统有变更,或者业务有变更,肯定需要跑测试,涉及到的测试都需要跑。
    • 如果什么都没有变化,就不太需要跑了吧。
  • 官方文档

python 模拟工具

  • pyMox
    • 感受
      • 语法初看起来难懂,懂了之后觉得好亲切
      • 文档齐全,使用简单,居家旅行必备
      • 不过看完 stub 和 mock 的介绍,感觉这个框架没分清 stub 和 mock 的区别
  • fudge
    • 文章介绍了下,感觉还可以,不过还没用过
  • 更多

python 测试框架

  • 原生的 unittest 还不错
  • nosetest 在测试理念上更加工程化
  • 入门文档

书籍

  • .NET 单元测试的艺术
    • 每个单元测试最好只有一个 mock 对象,多个桩对象

敏捷软件开发