代码风险分级

March 29th, 2011

（本文基本上出自 FindBugs ）

阻碍风险

逻辑正确性风险

这些缺陷模式的出现可能意味着程序员错误地描述了代码逻辑，从而导致程序行为出错。例如：

  • 不可能的类型转换。
  • 永远为假的 instanceof 操作
  • 对 null 调用 equals 方法
  • 对不同类型的对象进行相等性比较

多线程正确性风险

这些缺陷模式的出现可能意味着程序员对多线程环境编程不熟悉，在程序运行中可能随机引发错误。例如：

  • 对 Boolean 值同步可能导致死锁
  • notify() 或 wait() 不配对
  • 对 readObject() 方法同步
  • 错误的静态变量缓式初始化

关键风险

易受恶意代码攻击

这类缺陷模式表示代码没有足够的封装或是放松了已有的封装，在极端情况下可能遭受恶意代码的攻击，或引入不易诊断的错误。例如：

  • 以返回可修改对象的形式暴露内部细节
  • public 访问级的 finalize() 方法
  • 非 final 的成员变量
  • 在成员变量中保存可修改的容器

安全性风险

这类缺陷模式可能意味着程序员没有充分考虑安全性需求，可能降低系统的安全性水平。例如：

主要风险

性能风险

这类缺陷模式可能导致系统性能水平不必要地降低。例如：

  • 不必要的原生变量装箱/拆箱
  • 显式调用垃圾收集
  • 调用低效的浮点数构造器
  • URL 的性能缺陷

不佳编程实践

这类缺陷模式指示出不够好的编程习惯，会给维护带来困难，特殊情况下有可能导致程序行为错误。例如：

  • 用 == 或 != 进行字符串比较
  • clone() 方法没有调用 super.clone()
  • 丢弃异常
  • 用 removeAll() 方法清空容器
Posted by gigix Filed in

太阳底下没有新雪

March 29th, 2011

胡凯说，他用了五年时间 从纸卡回归纸卡 。

用胡凯惯有的乐观态度，这事情是一个学习思考和成长的过程。

用我惯有的悲观态度，这就是个傻逼事情。人家老早跟你说过了，你不听，绕个大圈子终于绕回来。好不好早点听老人劝呢？

我惯有的悲观态度之关键在于：大师们当初那样说，其实早就考虑到了各种情况。只是你不知道。你以为自己有了新想法。你以为自己在创新在改进。其实呢，太阳底下没有新雪。过了很久以后你才明白，其实你想的那些，大师们都想过了，想过了才跟你那样说的。你只是自己折腾着玩。

真正不幸的是我每每看到的创新思维无非分成两类：
  • 跟大师们说的一样。很遗憾，你只是想明白了人家二十年前就说过的事。
  • 跟大师们说的不一样。很遗憾，你搞错了。

考虑到比如穆斯林从两千年前就在打仗直到今天还在打仗这种事情，这世界还真是令人感到可悲啊。

Posted by gigix Filed in

转战西安

March 28th, 2011

上周末公司AwayDay，所有人来了西安。去兵马俑，唯一的乐趣就是拍一大堆 同事的人像 。然后就留在西安了。

据说按照招聘网站的职位搜索，DevOps是2010年的大热门 ：虽说经常跟“Java”、“C”、“Ruby”之类的词汇同时出现，但“DevOps”是2010年增长最快的职位描述关键词。

然则，为什么 OPs的书 我还是读不出乐趣来呢？ITIL 这样的流程框架读起来实在是味同嚼蜡啊…

而且据 @DEVOPS_BORAT 说，每个优秀的DevOps背后，都藏着一个被热妞拒绝的悲催故事。

凌晨三点起来恢复系统有木有！！！
新版本上线就当机有木有！！！
敏捷！！！敏捷你妹啊！！！
OP都是折翼的天使啊！！！
你伤不起啊！！！伤不起啊！！！

周六在 西安OpenParty 做了一个简单的DevOps介绍，还偶遇了 鲍老师 。其实说到DevOps的“怎么做”，很常用的 引入变化的技巧 仍然适用：

  • Start small and build on trust and safety
  • Create champions
  • Use metrics to build confidence
  • Celebrate success
  • Exploit compelling events

有235人在用 1.HourFor.Me ，我也小celebrate一下。也～～

Posted by gigix Filed in
5 comments »

DevOps: How To Start

March 18th, 2011

(Stolen from Evan Bottcher )

How to assess the current situation?

I would start by drawing a big visual map of the path from developer check-in to production, including the likely integration of multiple streams of work. Have the teams estimate the time taken in each stage, likely delays etc. This can be quite enlightening when seen from a total value-stream view – as few people will have the whole picture at present.

Categorise time and effort as ‘value-add’ vs ‘non-value-add’. E.g. time in manually testing from scripted scenarios is non-value-add as a computer could do it more quickly. Manual testing for exploratory testing is probably value-add, if it is genuinely finding defects.

Metrics would be build times, deployment time, how long does it take to configure an environment. How many defects are found, how many are true defects, how many are configuration and environment?

How to shape an improvement plan for “last mile”?

Need to prioritise areas of concern from your map of the path to production. Root cause analysis should be done to understand the cause of delays and defects. Spend some time setting a vision for what the best path to production would look like for the customer, and build out a set of steps to implement those changes. E.g. “shift to trunk development”, “train staff in continuous integration”, “automate self-service production-like environment”.

Who is able to do this?

Need to quickly understand the source control, development practices, deployment environment and architecture in sufficient detail to be able to understand how to improve things. If it’s a unix target environment, best to understand something of that environment.

A generalised set of tools/tech/skills:

  • automation (e.g. capistrano, ruby, bash, powershell etc.)
  • source control, and methods to do trunk development and deployments (feature toggles and branch by abstraction)
  • configuration management – chef, puppet, whatever you can apply to windows servers if that’s in scope
  • understand the ops perspective – tools for monitoring, logging, plotting system performance and stability over time (nagios, ganglia, cactii in the open source area)
Posted by gigix Filed in

关于追求这件事

March 13th, 2011

有些事虽然你一直都知道它存在，但亲眼见到还是不一样，亲身感受到还是不一样。

比如说，一家标普300指数的IT企业，它的研发组织要求严格的TDD，要求100%的测试覆盖率，要求严苛的重构，连 JavaScript都必须符合编码规范 。它的运维团队使用Chef和EC2。它的测试团队进行端到端的自动化测试。它的业务主管们跟程序员坐在一起画界面原型和定迭代计划。

简而言之，他们做那些我们一直都知道是正确的事，并且坚持做，不找借口。

这才叫有所追求。

做能赚钱的事是不需要说的。谁都知道饿了要吃饭。所谓“以交付为核心”、“以达成任务为核心”这些话根本就是可笑：如果连交付都做不到，我为什么还要拿我的那份薪水？做到本来就理所应当被做到的事，不是有追求。

做正确的事当我能看到收益的时候，这也是不需要说的。地上掉了钱谁都知道要拣起来。只要吃下药去就能治病，这个时候不吃的人是傻子。仅仅不做傻子，不是有追求。

（当然还有一种可爱的态度是：做不到、做起来有困难的事就赶快贴上个“不可能”的标签然后心安。之所以它是可爱的，因为那不像成年人应该有的态度。）

所谓有追求，就是即使这件事做下去不会马上看到收益，甚至收益都不会体现在自己身上，但我知道这件事是对的，我就应该坚持做，不找借口。做不到的时候就承认做不到，然后向别人学习，希望自己下次能做到。

说到底，交付这件事，据说是只要有一帮中专生到北大青鸟培训六个月就可以干的。那么不追求把代码写写好，我去谈什么“以交付为核心”到底有什么意思呢？

就像我跟小朋友说的，如果你只想满足于交付收钱的话，那你真的会有麻烦，因为中国会写程序会交付的人有太多而且他们比你便宜太多。

Posted by gigix Filed in

这个春天，我感觉运维们鸭梨很大

March 12th, 2011

壹、穷人的EC2自动快照

用两个简单的shell脚本加一个crontab就能每周（如果你愿意的话，每天也可以）备份EC2的机器。今天在Ubuntu上玩各种东西把环境玩复杂化以后，发现这个脚本蛮有用。

话说，实在没有什么理由，不到EC2搞台机器放自己的博客兼作翻墙梯啊…

贰、挪亚，不是方舟

这位John Vincent同志写了 一篇博客 论述…嗯，为什么有Chef和Puppet还不够。

Chef和Puppet管理有计划的变更，但你经常会做无计划的 偶发变更 ，而且你不太希望每次变更重启都得重启服务。所以，Vincent桑说，你需要…

Distributed coordination, dynamically reconfigurable code, elasticity and environment-aware applications.

然则，看完 Noah的README 就知道了。这就是RESTful的RMI…好吧，正确的思想永远都用得上，而且RESTful总比RMI要好那么一点点。

叁、飞禽走兽们

Nagios 是老牌的监控工具，十多年历史了。

Hadoop 这里好玩的东西不少，分布式文件系统 ，MapReduce ，还有 重新发明轮子的ZooKeeper 。

Sinatra ，快速做一个web server，不需要Rails那么庞大，比WEBrick容易写。

Redis ，又一个key-value store。加上 Ohm ，好了，NoSQL的对象持久化。

看一遍 Noah的使用场景 ，感到运维们鸭梨很大。

（还有一本 Hadoop的书 可我今天看不着…等明天翻墙再说吧。）

肆、来点音乐

Music as Data is a live programming language/environment based on Processing.org written in Clojure. It’s something like SuperCollider or Chuck but aims to be easier to hack/experiment live.

我喜欢他的网站。简约而不简单。

Posted by gigix Filed in

Chef学习手记之叁：红宝石菜谱

March 2nd, 2011

有了一台 基本的服务器 ，现在我就要在上面配置Rails服务器。当然这件事已经有人干过了，但我不想用别人的菜谱，再怎么说我也是 RubyWorks 的开发者…

（还有，我觉得Fedora还是不如Ubuntu好用，所以我偷偷把EC2的机器换成了Ubuntu 10.04。）

新建一个菜谱真容易，用knife一下子就搞定了：

$ knife cookbook create my_rails_gig

菜谱放在 #{chef-repo}/cookbooks/my_rails_gig 下面。首先要看的是 recipes/default.rb ，缺省菜色的做法就写在里面。在我开始做自己的配置之前，我得先保证Apache和 Passenger 都配好了。

# default.rb
include_recipe "passenger_apache2::mod_rails"

然后涅，我要用“railsapp”这个用户来部署Rails应用──不可以用root来跑服务。所以我得确保有这个用户（以及它独占的一个组）。

# default.rb
 group 'rails' do
  group_name 'rails'
  action :create
end

user 'railsapp' do
  username 'railsapp'
  action :create
end

接下来，按照我们RubyWorks的传统，Rails应用应该部署在 /var/rails 目录下面。所以要确保有这个目录。

# default.rb
deploy_to = '/var/rails'

directory deploy_to do
  owner "railsapp" 
  group "rails" 
  mode "0755" 
  action :create
end

现在是最挑战的部分：配置Passenger…但是只要是像我一样经验丰富的Rails服务器管理员，这个也小菜一碟_ Apache2那本菜谱 讲了怎么在Apache里做web_app，你只要调用就行：

# default.rb
web_app 'rails_app' do
  template "rails_app.conf.erb" 
  docroot "#{deploy_to}/current/public" 
  server_name "#{MY_COOL_HOSTNAME}" 
  rails_env 'production'
end

唯一的trick就是 rails_app.conf.erb 这个template：我需要把它放在 templates/default 目录下（规则和Rails有点像）。别的么…就再没啥啦～～（不信就 看代码 ）噢对了，别忘了在这台机器的角色里加上新的菜色：

"run_list": [
            "recipe[passenger_apache2::mod_rails]",
        "recipe[my_rails_gig]" 
    ],

噢也～菜谱写完开始做菜～先把菜谱上传到服务器：

$ knife cookbook upload my_rails_gig

再跑到我的服务器上执行一下 chef-client …这就好了。用 railsapp 用户到 /var/rails/current 下面建一个应用（为什么要“current”？问 Capistrano ）。浏览器访问80端口，看后台日志，Rails已经开始工作了。

嗯，虽说写自己的菜谱挺好玩的，不过 这个菜谱 很值得学习──其实很多菜谱都值得学习，所以…

（未完待续）

Posted by gigix Filed in