毫不掩抑的说我的google重度使用者，几乎尝试过所有的google服务，其中gmail和gdoc应该最重度的用户了。另外，同步之前尝试过n多种，最终选择的是dropbox，而且是重度用户，虽然用着还不错，但是总希望google能出一个类似的服务，或者收购dropbox；所以当Google Drive发布后第一天就翻山越岭的过去瞧瞧，提交申请等待，今天早上收到激活通知，迫不及待的体验了一把，过程网上一大堆，不多说。

最纠结的自然还是被墙，虽然早就麻木，但每次都修改hosts，proxy还是让人心生厌烦，心想着何时我们才能真正的网络自由。

整个体验过程还算顺利，和dropbox真的差不多（skyDrive好像也差不多），逻辑基本一致，本地创建一个文件夹和云端保持一致，还可以同步到android等移动设备；但是Google Drive不同的是和google doc做了整合，会把线上的google doc全部同步下来，这个真心很好（其实我觉得他应该创建一个docs目录放文档～），我差不多好几千份文档，很快就同步完了（后来查了下，是因为他只同步了文档索引，每个文件才153 bytes，例如{“url”: “https://docs.google.com/Doc?docid=0AQSsdoBxI0TDZGhmODZrcjlfMzUsswaHZtaGI”, “resource_id”: “document:0AQSsdoBxI0TDZGhmODZrcjlfMzUsswaHZtaGI”}）；。更有价值的是装个google离线可以离线编辑，于是在想有没有可能谁出一个离线撰写google doc的软件，真心喜欢google doc的快捷键，真心不喜欢ms word和mac下的pages，希望有人能写一个google doc格式的文档撰写软件。

最后说一说Google Drive对dropbox的影响，个人觉得会有部分影响，尤其是国外网络自由的情况下，google的这个服务真心不错，而且加上gmail的帐号系统，在线编辑，共享和协作都很方便；但是影响不会致命，dropbox毕竟把这个服务做到了极致，一般做到极致的服务都是有前途的，或许哪一天就被哪个大佬诏安了，或者和我另外一个重度使用的服务evernote合并吧，哇卡～

如果您对Google Drive感兴趣，推荐快捷键：

http://support.google.com/docs/bin/answer.py?hl=en&answer=1295935&p=docslist_shortcuts

Fenng曾写过一篇《为什么 Stack Overflow 会如此成功？》，对，很多人都会问为什么StackOverflow如此成功，而且还仅仅只是开始，以后会成长成啥样的还不不晓得，但是从大家全部的赞叹中还是说明StackOverflow是非常成功的。

StackOverflow给我最大印象的有两个：

1. 模式

系统自身是wiki＋digg/reddit＋blog＋forum的结合（下图），通过威望值(Reputation Point) 与徽章(Badge) 建立起信任评价体系，并且做到对参与者的有效激励。

2. 遴选机制

stackoverflow的评价机制非常有意思，和百度贴吧这样的问答系统正好相反，他的最佳答案是由网友dig出来了，而且如果有人的回答不好，还会被修改掉或者直接删掉

有人感叹说：

在国内是做不出这种网站的， 国人素质问题， 我使用stackoverflow深感其用， 关键是开放， 不并单单指奖励机制，我有好几次发的帖和答案（在stackoverflow上）不太好， 都被别人删掉了， 真刺激我的神经， 但忍了， 因为他的高质量就这样来的，但在国内出现这样的情况， 那个网站肯定被人骂得狗血淋头了，例如我经常看到有人骂javaeye的论坛不让发帖等等之类。

很有意思，值得研究一下～

问了下出版社的编辑，说是人邮里出版的android书里销量最好的，颇感意外，看到很多人加入android阵营，也有点欣慰～

这本书当时写的还是比较匆忙的，主要是针对android入门开发者的，很多地方也写的不仔细，比如代码有点多，代码没有很好的格式化，内容偏简单，系统化不够等等～ 书中的例子也有点比较老了，例如yobo的api已经不能使用了，豆瓣的api也有了更新等等～每次读者在社区问书上一些问题的时候，我都觉得蛮愧疚的，毕竟内容比较老，会误导一些读者～

这本书是国内第一本android的技术的书，当时的android sdk还是1.5版，上市快3年了，内容相对偏老的，出版社一再催我能更新到最新的sdk版本，再把之前用户反馈比较多的问题完善下～是不是真的需要抽点时间来出第二版了呢？

最不习惯的就是是文章的格式，一堆html代码，技术的人好像都有洁癖，我现在写的都是在html模式下至今写的，非常排斥WYSIWYG编辑器～一堆没用的格式代码～很不干净～

其实比较成熟的标记语言还是有不少的，比如wiki format，又比如今天要讲的Markdown，甚至还有国内bbs喜欢用的bbcode都还是不错的标记语言，这里主要讲的是Markdown和Mou。

http://apple4.us/上有篇文章写的不错《为什么作家应该用 Markdown 保存自己的文稿》，其中说了为什么作家需要用Markdown保存自己的文稿，其实对技术人员也一样有用，大家可以仔细看看～同时被介绍的还有Mou（Mou The missing Markdown editor for web developers）。

Mou真是个不错的东西，让不会编程的人也很快接收其用法，当你已经熟练掌握其语法后，其实也可以不用Mou，比如技术人员一般直接在textmate里写或者直接写都还蛮不错的。

大概汇总下用 Markdown 有如下好处：

1. 干净，只写你需要的文字和标记，没一堆乱七八糟的html
2. 简单，真简单，就那么些标记，不需要10分钟你就学会了；
3. 纯文本，占的空间小，打开块，记得空doc还有11k；
4. 兼容性好，就是文本，文本编辑器都可以打开编辑，最不喜欢的就是.doc或者.gage，那个兼容性呀，简直是噩梦；
5. 显示可控，无论是转html，还是又mou这样的工具，还是直接处理，都非常简便；
6. 其他

技术人员如果能坚持写技术blog都能用Markdown保存下来，其实是一个不错的宣传，wordpress会不会又被我废弃，直接写个轻量级的日志引擎，难说～

参考：

http://kramdown.rubyforge.org/documentation.html

https://github.com/tanoku/redcarpet

http://zh.wikipedia.org/wiki/Markdown

source ~/.git-completion.bash

这样就能在bash下用tab自动补全git命令、branch等内容了。也可以为系统上所有用户都设置默认使用此脚本。Mac 上将此脚本复制到/opt/local/etc/bash_completion.d 目录中，Linux 上则复制到 /etc/bash_completion.d/ 目录中。这两处目录中的脚本，都会在 Bash 启动时自动加载。

在输入 Git 命令的时候可以敲两次跳格键（Tab），就会看到列出所有匹配的可用命令建议：

$ git co<tab><tab> commit config

此例中，键入 git co 然后连按两次 Tab 键，会看到两个相关的建议（命令） commit 和 config。继而输入 m<tab> 会自动完成 git commit 命令的输入。

命令的选项也可以用这种方式自动完成，其实这种情况更实用些。比如运行 git log 的时候忘了相关选项的名字，可以输入开头的几个字母，然后敲 Tab 键看看有哪些匹配的：

$ git log --s<tab> --shortstat --since= --src-prefix= --stat --summary

这个技巧不错吧，可以节省很多输入和查阅文档的时间。

因为是第一台，所以一点经验没有，之前连傻瓜相机用的都少，只偶尔用iphone拍点图像，所以对快门，光圈，曝光，景深，白平衡记本上是没概念的，之前查过一次资料，在Nikon D90，Canon 600D，Nikon D7000等几个之间有过选择，之前在微博上问过达人们，C家和N家都有一大群的粉丝，每个人都能说出一大堆的理由～

搁置了一段时间后，眼看着春天来了，外面光秃秃的树杈也渐渐的有了一点活力，想着也需要给自己找个借口出去走走了，于是再次选了单反，几经比较后，还是选择了Nikon D90。理由不多说，中间也考虑过Canon 600D，后来应该还是看中Nikon的专业性，D90的高性价比吧～

机器手感不错，做工精良，虽然是08年的机器，但还是很气派的，晚上抱着D90说明书，又把前面买的《跟我学摄影》翻出来看了看，还真学了不少之前觉得很复杂的知识，再次体会到，如果你想学什么，就投入进去，尝试着喜欢上，然后你就应该能更有兴趣的学习了。

第一台单反，完成《2011计划年度总结回顾,2012年预期》中的一个目标，此文仅为纪录。接下去会花下时间多多练习，争取能拍出一些不错的作品～

有些人可能对我多少有些了解，应该算国内第一批开始搞android相关的人，09年创办的android开发社区（eoeandroid.com）现在也是国内android开发人员最活跃的社区，我写过一些代码，也写过一些技术的文章，也做过android应用，也见过很多android的技术，也给公司（eoe）招了不少android技术人员，也给不少朋友奇特推荐过android技术的人，我下面会分享我对android技术人员招聘的一些看法。

1. 首先看为人：品性很重要

或许是因为我们是创业公司，会严格选择每一个进来的人，特别是技术的人。技术很重要，但是在我这边不是第一位的，人品和性格是第一的，创业公司唯一不变的就是变化，如果人品不过关的人肯定待不住，如果性格合不来的人肯定待不久。有人说这个很虚，见一面怎么可能看出品性，其实不难，一举一动，言语措辞都很简单就可以看出一个人的内在（因为技术的人为人真的很简单），所以，如果你去面熟，表现真实的自己，对公司，对个人都是有好处的，合得来就是合得来，合不来强求也没用，这本是个双向选择的事情，不存在谁强势谁弱势。积极，主动，自信，阳光是比较好的品格～

2. 接着看技术：基本功需要有体系，够扎实，思维要跳跃

如果来eoe面试过的人应该知道，我们面android有一套笔试题，但是java的，很多人不理解可能会问我来面android的为啥让我做java的题？其实很简单，java是基础，我们的笔试题会涉及到基础的，算法的，开放性的试题，我们需要全面的了解一个人。每个题目都很重要，所以，如果去面试，如果对方是精心设计的题，请认真一点回答，记住认真不是死板，答题看的是基础和思维，细节无所谓，因为有真正干活的时候有google，有api～

3. 然后看经验：经验很重要，你必须对你做过的项目了如指掌

做完题目，我们一般就正式面试了，会问问笔试题目上你的感觉和具体一个问题的思路，然后才开始问之前的经验，我们的要求是必须真正做过项目，如果没项目，应用也行，其实需要的就是一个关键点：你真正操作过一个应用，对你做过的模块必须了如指掌，我们不会问太多项目，让你一个最熟悉的或者最喜欢的项目，问的很细节，细节到你证明这个项目自己之前是用心做的，或者证明你在这个项目就是个打酱油的。

然后会问点和android相关的东西，一般容易的，中等的和比较刁钻的问题都会问一些，刁钻的比如会问你现场保护的机制，方式，为什么要现场保护等等问题，如果你是个做技术爱思考的人，这些问题应该不难，如果你虽然做过1－2年android，但是每个方面都很泛泛，那你肯定会被问的傻傻的。

最后会问一些开放性的问题，都是很随机的题目，比如桌子上的一个杯子等等都可能会被问～～这个地方主要看整体的思维和分析问题的能力。

4. 做决定：合适还是不合适，或者留题目，做个小测试

如此过程，我们基本上就能判断一个人是否符合我们要求，如果不满足，我们基本会很直接告诉原因是什么，哪个地方我们觉得不合适，你以后应该注意什么？如果我们觉得满足预期，可能就收了；如果我们拿不准，但是觉得你潜力很好，可能会留个题目，做个小东西，不会很难，做的时候请注意自己的编码风格，整体项目结构等等，这些是关键因素～

如上过程，就是我在招android技术人员的一些思路和过程，我们是创业公司，相对看的更全面的能力，但是我个人觉得企业的思维或许都差不多，如果你要找android相关的工作，请参考～

另外，android开发社区 里有很多企业招聘android技术人员，大家可以多关注，希望大家能找到自己满意android工作～记得经常来android开发社区活动～

再顺便提一下，我们（eoe）长期招合适的android技术，如果你有兴趣，可以联系我～

今天下班得时候发现提示10.7.3下载完成可以安装了（mac好像把更新版本放在后台进行，下载完直接提示用户安装了），迫不及待更新，看到如下

装完后就开始装上次下载得messages beta，下载完安装（需要重启，好像第一次遇到mac安装完软件需要重启），而后就可以用自己得apple id来登陆了，登陆完就可以给其他联系人发message信息啦～

但是也发现一个问题，手机端收到得信息是按字分割得，还不晓得是什么原因，是中文得原因？

之前晓得有两个方案可以使用
1. 用类似use_db这样的插件，实现针对model的读写分离（其实这个不是真正意义上的读写分离，但是可以凑合用）
2. 用类似master_slave_adapter和masochism插件实现真正意思上的读写分离，配置稍微麻烦点，有的可能还需要一些hard code～

也在ruby_china发了帖子和大家讨论了下（http://ruby-china.org/topics/1397），在大家的回复了，看到 @kevinxu 提到了db-charmer (https://github.com/kovyrin/db-charmer)，也看到 @ShiningRay 提到了data_fabric，还有 @bony 提到了可以自己来拦截“拦截一下activerecord的方法，在读操作和写操作时重新设置connection”。

于是就去多查下资料，看到有如下ruby-toolbox上有个Active_Record_Sharding的页面（https://www.ruby-toolbox.com/categories/Active_Record_Sharding ），里面还提到了了Octopus这个gem（https://github.com/tchandy/octopus），于是仔细看了一下Db-charmer这个还是比较完善的，按照其描述是这样的：DbCharmer is a Rails plugin (and gem) that could be used to manage AR model connections, implement master/slave query schemes, sharding and other magic features many high-scale applications need. 然后找到几篇不错的介绍文章
DB Charmer – ActiveRecord Connection Magic Plugin
http://kovyrin.net/2009/11/03/db-charmer-activerecord-connection-magic-plugin/

DbCharmer 1.7.0 Release: Rails 3.0 Support and Forced Slave Reads
http://kovyrin.net/2011/09/01/dbcharmer-1-7-0/

db-charmer github
https://github.com/kovyrin/db-charmer

db-charmer homepage
http://kovyrin.github.com/db-charmer/index.html

看到几经完善，现在也已经支持rails3了，没仔细测试，也还没来得及看源码，有空的可以看后分析下，我主要考虑稳定性和扩展性～

这个代码有2个主要的问题：
1. 慢
2. 耗内存

于是我们有两个解决方案，分别是：

1.用libxml-ruby替代nokogiri，因为nokogiri优势是读取的快，写的花一般，用libxml-ruby可以这样

require 'rubygems'
require 'xml'
doc = XML::Document.new()
doc.root = XML::Node.new('root_node')
root = doc.root

doc.save('foo.xml', :indent => false, :encoding => XML::Encoding::UTF_8)

执行的结构类似
ice@mac:/source/labs/xml > time ruby test_xml2.rb
real 0m50.065s
user 0m4.594s
sys 0m0.509s

2. 直接写，示范代码如下
f = File.open(“foo.xml”, “w”)
f.puts(““)
f.puts(‘‘)
500000.times do |k|
f.puts “ ”
end
f.puts(‘‘)
f.close

运行结构类似这样的：
ice@mac:/source/labs/xml > time ruby test_xml.rb
real 0m0.974s
user 0m0.813s
sys 0m0.063s

从上面可以看到，效率差别还是蛮大的，回到我自己的case里来，原来需要6个小时的job现在不要30分钟就搞定了（自然还有一些其他的优化，就不细说了）～～