Gawain's Jail

• 取字符串的长度：${#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阅读器了。

到今天宝宝出生已经一个月了。其实从出生前就一直在想给宝宝起个什么名字，结果到宝宝出生都没能定下一个名字来。头一段时间我还在推上请大家给赐个名。大家给出了不少的好名字，因为宝宝是早晨生的，老黄给起了个白晓天，@zoomq给起了个白晓生，同事@xklxkl给起了白慕天。更有朋友@heqian建议叫白展堂，这样比较响亮。

家人在讨论的过程中也一直没有什么定论，有一天我翻《老子》，到了第27章的时候，看到一个词叫袭明。

善行无辙迹。善言无瑕谪。善数不用筹策。善闭无关楗而不可开。善结无绳约 而不可解。是以圣人常善救人，故无弃人。常善救物，故无弃物。是谓袭明。故善 人者不善人之师。不善人者善人之资。不贵其师、不爱其资，虽智大迷，是谓要 妙。

袭明这个名字，老婆觉的这个袭字太过锋芒，我父母则觉的"明"字与我的太爷爷辈的名字有冲突，入不了家谱（按家谱应该叫白茂*）。但是过了一段时间也没能想到更好的名字，所以也就把这个名字定下来了。

孩子还有一个小名叫丁丁，是由他的姥姥和姥爷在他还没出生时起的一个名字演化来的----白丁，对，就是"往来无白丁"的那个白丁。

WWDC的keynote已经过去了，直到今天早晨我才在iPhone上看完视频。总体来说我想要的东西，Apple没发。

iPhone 4的过人之处有三：

1. 强悍的电力，300小时待机啊，300小时啊。
2. 高精细的屏幕，326ppi啊，326啊。
3. 三轴的陀螺仪，三轴的啊，三轴啊。

我本以为Apple为回应Google IO的动作把MobileMe给免费了，再搭上个无线同步。这种事情也许将来有吧，但是这次是没出。我猜没出的原因如下：

• 苹果目前还无意指染云端。虽然苹果一定在搞云端工程，但现在可能不是推出的时候。
• 云端同步的带宽还不够快。每次同步都backup，如果为了云端同步而让同步过程速度变的更慢，老乔是不会答应的。当然现在已经很慢了。
• 苹果目前的技术整合能力还没有到这一步。收了lala之流的公司还没来得及完全整合。

• 在线的音乐流服务。
• 在线的高清电影流服务。
• 更高速的网络。
• MobileMe准备好免费接纳现有的iPhone用户。

就现在Apple放出的玩意来看，比Google弱的事情主要在TV上，和Google TV相比Apple TV真是太烂了。Android现在能直接把视频流推给Google TV。iPhone你是要到iOS 5能支持还是iOS 4.x就能支持呀，还是等你出了Apple TV二代才行啊。说实话推视频这个功能真的是超赞的，有赤裸裸的需求的。

Apple，自上次Google IO之后，我觉的你还得再加把劲才做的稳头把交椅。

记点笔记：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. 一个引用计数。