Recently in note Category

• 取字符串的长度：${#VAR}

# a="HelloWorld"
# echo ${#a}
10

• 字符串截断：${VAR:POSITION}或${VAR:POSITION:LENGTH}

# a="HelloWorld"
# echo ${a:5}
World
# echo ${a:4:3}
oWo

• 字符串匹配取最短：${VAR#SUBSTRING}和${VAR%SUBSTRING}

# a="HelloWorld"
# echo ${a#*o}
World
# echo ${a%o*}
HelloW

注：#是从前向后，并且*号是紧随着的，而%则是从后向前匹配。*号是放在最后的。

• 字符串匹配取最长：${VAR#SUBSTRING}和${VAR%SUBSTRING}

# a="HelloWorld"
# echo ${a#*o}
rld
# echo ${a%o*}
Hell

• 字符串替换：${VAR//PATTERN/REPLACEMENT}

# a="HelloWorld"
# echo ${a//World/Earth}
HelloEarth

• 确定匹配位置：expr STRING : REGEX

# a="HelloWorld"
# expr $a : ".*o"
7

注：这里的REGEX从名字上就说明了是一个正则表达式。

Update：详细请参考

• Advanced Bash-Scripting Guide: Table B-5. String Operations
• The Geek Stuff: Bash String Manipulation Examples - Length, Substring, Find and Replace

• 革新的步调----革新的步调正在加快。高度关注基础设施的革新可以降低成本、增加可靠性并且减少资源的消费，最终的目的就是降低成本。
• 钱都花哪儿了？----
  • 54%花在服务器上，8%花在网络上，21%花在配电上，13%在电力上还有5%花在其他的基础设施上了。
  • 34%的成本与电力有关。
  • 电力成本有上升的趋势。
• 云效率----服务器的使用率在咱们的工业里是10%到15%。
  • 避免在基础设施中使用漏洞。
  • 把工作拆成小份，并且尽可能的将他们排入队列。
• 配电----11%到12%的电力消耗在了配电的过程中。一些最小化电力消耗的规则
  • 把电力都卖出去，只要电力允许就放置更多的服务器。
  • 避免使用变压器。
  • 增加电力转换的效率。
  • 高压越接近负载越好。
  • 使用效率高的电压整流设备。
  • 高压直流是一个小的潜在利益。
• 机械系统----一个可以节省空调的环节。
  • 什么是可以被改进的？冷却塔，热交换，泵，蒸发器，压缩机，冷凝机等。
  • 上述这些系统的效率取决于对不同温度的需求。
  • 冷热系统分离
  • 增加服务器的运行温度。
    • 通常在61到84
    • 电信标准是104F(40C)，游戏行业要更高一些。
• 温度
• 限制到高温运行的因素
• 避免整体直接澎涨冷却
• 过滤微粒和化学污染
• 网络安排
  目前的网络是超订了
  • 强制放置有序
  • 目标：所有点到数据中心的距离是一致的。

1. 太多的数据库请求

在一个请求或事务中数据库请求太多。具体有三种现象：

• 请求的数据多于实际使用的数据。
• 同样的数据请求多次。
• 多次的请求一个必然的结果集
2. 同步走向死亡

同步是一种保护共享数据的重要机制。但是过度的代码同步就会引发性能问题，这种问题在单机的时候并不明显，但是在一个高负载的环境下就难以持续了，最终的结果就是死亡。如何确定同步问题，可以把程序的CPU时间和总体执行时间在递增负载环境下做测试对比，就会发现CPU时间几乎是一定的，但是总体执行时间是随负载增加而快速增涨的，那就是说这个程序在同步上是有问题的。

3. 过多的远程调用

许多的库都是一些远程调用，对于程序员来说，本地调用和远程调用在程序上并无差别。但是不要忘记了远程调用的额外成本，比如：传输时间、序列化、网络流量以及内存使用等等。

4. 错误的使用ORM

ORM从开发人员手里接过了载入和存储数据的重担。ORM的框架一般都有许多的设置以供优化，在使用时候如果使用了错误的设置，就会导致一些不可预见的性能问题。所以在使用框架的时候对于其设置项要真正的了解其内部的工作方式。

5. 内存泄漏

垃圾回收并不能阻止内存泄漏，所以尽可能快的释放对象引用是非常重要的。

6. 成问题的第三方代码或组件

代码是人写的，是人写的就会有问题，但是问题有多有少。所以在引入第三方代码或组件的时候最好是深入检查一下，以免从A产品的开发人员演变成B组件的捉虫队。

7. 贪婪的占用稀缺资源

像内存、CPU、I/O、数据库啥的都是稀缺资源，所以就别占着矛坑不拉屎（这也是人品中重要的一项，我相信一个人品好的人写代码的时候也会这么做。）。

8. 肥胖的前端

太肥的东西总是要避免的，不管是吃、看还是用。

9. 错误的缓存策略导致额外的垃圾回收

缓存对象到内存是为了避免重复的数据库请求。但是如果把太多的数据都缓存到内存或是数据对象是频繁被更新的，那这样的缓存策略带来的问题就是要做更多的垃圾回收工作。

10. 间断性的问题

这种问题较难发现，通常出现在特别的输入或是某个确定的负载情况下。这只能是尽可能的做全面的测试，从功能到负载和性能都覆盖到，这样就尽可能早的把这种给问题给揪出来，从而不影响到真实用户。

11. （额外送的）昂贵的序列化

在现在的Web应用中序列化随处可见，REST大行其道，数据对象要序列化之后再通过接口才能送出去。有序列化就有反序列化，这种开销是对称的，所以要尽可能快速的处理这两个问题，而且还要考虑到其序列化后数据的大小，内存占用等问题。

每年几乎都要来这么一次，最近想整理一下的原因是周围有两个同事相继加入Mac党，帮他们安装设置了一些工具。所以就顺手也整理一下：

• 网页浏览
主要使用的还是Safari，同时也挂上了Glims。安上Firefox的主要原因是Y!slow和Firebug，同时为了有更好的界面效果，还搭上了foxdie.us。
• 网络下载
FTP的主要工具是Cyberduck和在Terminal.app使用的ftp命令。cURL则是一个下载以及测试的利器。
• 文本编辑
虽然Textmate一直不思进取，2.0杳无音讯，跳票情况超过暴雪，但是今年还是团了一个License，确实是码农必备。另外在写中文文档的时候也会用到TextWrangler。
• 文档编写
公司里有太多的人使用Word和Excel了，所以也会安装一套M$的Office 2008来用。文档的编写一般是趋向于纯文本方式的，如果有格式要求我更趋向于使用TeX，自然也就会安一套MacTeX来用。安装iWorks主要是冲Keynote去的。
• 绘图处理
OmniGraffle绝对是Mac上的超牛B软件画图软件。对于照片的管理还是用了自带的iPhoto，虽然以前下载了Aperture回来试用，但是对于我这样的傻瓜用户还是有些太高级了。一般的裁剪工具就是自带的Preview.app。思维导图则是MindNode.app比较好使。
• 影视娱乐
看电影必用的工具是Perian，VLC和Movist。一般情况下会先用QuickTime来播，如果不行就换Movist，再不行换VLC。在家接上电视的时候也会用Plex来放电影，不过这个情况要少一些，可能等我在家里搞起一个电影库的时候就有用了。RealPlayer已经从我的安装清单里去掉了，下载电影的时候也基本上不下RMVB了。
• 聊天通信
我平常几乎只开iChat挂Google Talk，偶尔会开一下Adium和QQ。
• 杂项
• Nally.app是读BBS的利器
• The Unarchiver.app可以通吃所有的打包档。包括rar的字符集问题处理的都不错。
• Tweetie.app是发推利器，而且支持民间RT。
• iCompta.app来记帐是节源的好工具，不过要坚持下来才可以。
• HandBrake.app来转档给iPhone使。
• Evom.app也是转视频档给iPhone使的工具。
• CoRD.app可以连接Windows远程桌面。
• iChm.app可能是Mac上最好用的chm阅读器了。

记点笔记：High-Performance Server Architecture

性能问题一般因以下四个原因而起：

1. Data copies(数据复制)
2. Context switches(上下文切换)
3. Memory allocation(内存分配)
4. Lock contention(锁争用)

为避免Data copies，作者使用的方法是间接使用和通过buffer descriptor来代替buffer pointer，每一个buffer descriptor由以下部分构成：

• A pointer and length for the whole buffer. 一个指向整个buffer的指针和大小。
• A pointer and length or offset and length for the part of the buffer that's actually used. 一个指向buffer实际使用部分的指针和大小或偏移量及大小。
• Forward and back pointers to other descriptors in a list. 指向其他描述符的向前及向后的指针列表。
• a reference count. 一个引用计数。

前些日子从朋友那里拿了一个iPhone 3G。拿过来时候基本就是个砖头，推测是一个已经刷到3.1.3的有锁版，后来还拿去e世界的电玩巴士请帮解锁，未成功。回来查了一些资料及刷机的方法，自己也刷了几次。这次经历算是给我补了一把iPhone的课。

iPhone除了1代、3G、3GS的区别之外还有有锁版和无锁版的区别。有锁版一般是美国的和日本的，俗称美版和日版，应该也还有欧版的。国内的无锁版一般都是指港版。有锁和无锁的区别是有没有绑定了电信运营商，美版绑定的运营商是AT&T，而日版绑定的是SoftBank Mobile。正常来说绑定了运营商的iPhone只能使用绑定运营商的sim卡，然而非指定运营商的用户也想使用iPhone，于是就出现了卡贴，把一个非指定运营商的sim卡伪装成一个指定运营商的sim卡。后来有人通过软解的方式把iPhone的这一限制给破了，这个过程也就称之为解锁，但是软解的过程并不是一切顺利的，苹果也是通过更新软件的方式防止人们对iPhone进行解锁。最近的iPhone OS 3.1.3的升级就造成了iPhone 3G和3GS无法解锁的情况（我相信这只是暂时的）。目前iPhone 3G有锁版要是刷到了3.1.3并且baseband升到了05.12.01，那么得到的是一个增强版的iPod Touch。iPhone 3G升到3.1.3之后可以使用PwnageTool定制一个固件，选择不要升baseband，这样起码让iPhone 3G可以当个iPod使用。也可以刷回到3.1.2（这个过程会遇到1015的错误），再使用Blackra1n来解。

iPhone用户经常会提到的一个事情就是JailBreak，称之为越狱。越狱后就可以安装许多Apple Store之外的应用程序了。

iPhone用户经常会做同步操作，其实在同步的时候iTunes还会做备份的操作，如果你换了iPhone，那就可以使用"从备份中恢复"这一招把设置、联系人、Safari的书签等给恢复回来。但是要注意以前iPhone里的mp3、视频和买的应用程序就只能从iTunes中同步才能回来了。

在iPhone的刷机过程中要特别注意恢复模式和DFU模式的区别，最大的区别是DFU模式下屏幕是全黑的。进入DFU模式的方法是如下：

1. 关机
2. 同时按下Power+Home键不放，保持10秒
3. 松开Power键，Home继续不放，保持10秒
4. 松开Home键，进入DFU模式

就iPhone刷机升级这个事来看，没事别折腾。如果要折腾有几点忠告：

1. 无论何时都不要刷官方的新版，除非你是无锁版的，并且不想越狱。
2. 对自己的iPhone要完全了解。是否有锁？什么型号？baseband是多少？。
3. 熟读解锁软件的各个注意事项，一定要读，看看自己的手机是不是在可破的范围之内等等。

2009年又要过去了，一年又一年，日子总是追着走。

从工作、学习和生活三个方面去说，2009年做的事真是不多，有些得过且过的感觉了。年初我有许多的计划，可是到了年终，细细的数来却没能完成几样。生活上值得庆祝的事情，一来办了婚礼，二来呢做了准爸爸。工作上没有值得庆祝的事，只有值得反省的事。学习上的事情，是觉的学的太慢了，而且网撒的太大，有点收不住的感觉了。

2010年对自己的希望是：

1. 做一个好爸爸。
2. 多学一门外语。
3. 把学习的重点放在计算机科学上，不要再搞民科了。要深一些！
4. 广交好友，提升RP。
5. 在人大的学习该有个了结了。
6. 多了解一些微观经济学的东西。
7. 克服拖沓症。

发生在解析服务器和其它DNS服务器的传输时间，有三个原因。

• 无缓存。无缓存就要查其它的NS。
• 无法服务。要查的NS如果过载，就可能发生请求被丢弃或重发。
• 恶意的流量。DoS，重点是攻击，人为造成第二种情况甚至更严重。

无缓存的情况有一些数据，NS服务器拿到一个无缓存的请求，会导致至少1次的外部NS查询，一般情况会是2次以上。

根据Googlebot的情况来看，平均解析时间是130ms，然而还有4-6%的请求会直接超时，这通常是UDP丢包或服务器无法到达。把丢包，死NS，NS配置错误等因素都计算进来的话，实际的解析时间是300-400ms。

无缓存的情况较难避免，原因有三：

• internet太大而且还在成长。新用户和新网站都在增长，并不是所有的网站都是那么的流行，所以大部分的请求都是无缓存的情况。
• TTL太短，这个好象是个趋势，短TTL带来的就是更多的NS请求。
• 缓存是相对隔离的，NS大多放在LB设备下，缓存是随机的。所以就增加了无缓存的情况。

Google采用了一些方法，如下：

• 提供足够的服务器。
• 避免恶意攻击。
• LB使用共享的缓存。
• 预抓取名字解析。
• 提供全球服务。

• 对于静态内容在HTTP Header中设置过期时间和最大时间，可以有效的使浏览器避免下载已经下载过的文件。
• js,css,图片什么的都是静态内容，都应该考虑cache，但是html不是静态内容。
• Expires和Cache-Control: max-age是资源终身鲜活的Cache控制。浏览器在过期之前不进行资源的鲜活检查。
• Last-Modified 和ETag则是对资源的一种描述，属于启发式的Cache控制，浏览器在检查之后再决定使用Cache与否。
• Expires 和Cache-Control: max-age，作用相同，设置其中一个即可，Last-Modified 和Etag也是冗余的设置，设置其中一个即可。
• 设置Expires，Cache-Control支持率不及Expires。这个值通常设置1个月，不要超过1年。如果不知道过期时间，就设长一点，当发生变化的时候使用URL的指纹。
• 要考虑到代理服务器的Cache情况，使用Cache-Control的public还是private。通常来说要set-cookie的地方就不要让代理Cache，所以设置为Private。
• 代理Cache的情况还有压缩与否的问题，有两种方法，一种是把Cache-Control设置为Private，使代理服务器不Cache这些内容。另一种是设置Vary: Accept-Encoding的Header，这可以使代理Cache两种内容，压缩的与不压缩的。
• 避免Firefox的URL哈希冲突，Firefox的URL哈希算法有8个字符的冲突边界。所以两个资源的URL差异应该在8个字符以上。
• 设置正确的Vary Header，IE对于设置了Vary头的资源是不Cache的，有例外，Vary头的值是Accept-Encoding和User-Agent的时候可以被IE给Cache，所以要么不设Vary头，要么就对Vary头进行裁剪。

http://httpd.apache.org/docs/2.0/mod/core.html#keepalive
• http://en.wikipedia.org/wiki/HTTP_persistent_connection
• http://en.wikipedia.org/wiki/Keepalive
• Apache的KeepAlive设置与优化 - 老黄纸条箱（这篇是精华）

• 使用较少的CPU和内存
• 开启HTTP 管道
• 减少网络拥堵
• 在接下来的请求中，减少传输时间。
• 错误可以被报告但是不关闭TCP连接。

在RFC 2617第47页里，一个用户客户端对任何服务器或代理不能维持2个以上的连接。代理可以维持2xN个连接。

IE6和7使用 2个长连接，IE8使用6个，都是在60秒之后超时。 Firefox的长连接都是在300秒超时，同时使用的连接可以自定义（按每主机或总计），Opera与Firefox类似。