下班后去南瓜同学的创业办公室拿票。这个我五一不出去了，准备二号三号两天去参加这个首届杭州·西湖现代音乐节。说是"现代音乐节"，其实几乎清一色的民谣歌手。
"叶蓓的深呼吸将在午后的阳光中浸透西湖天地的大草坪，小娟米汤般醇厚的声音将在杭州的暮色中响起。还有久违的老狼..."，狗屁，狗屁宣传文案! 去你的叶蓓、小娟、没听说过的朱七甚至老狼，老子只听周云蓬，万晓利就好了！ 如果说更多希望听的，将会是王娟+虎子、姜昕、苏阳。
南瓜同学手里还剩下少数几张 2 号下午的票，还是 8 折的，如果有感兴趣的朋友可以在豆瓣上联系一下他或者是在我这里留言。我个人认为，2 号下午这几个歌手是最值得一听的。尤其是周云蓬，一个人就值回票价的。
另外，南瓜同学最近在打造一个很前卫的音乐网站。预计不久后即可新鲜出炉，现在他也在继续找 UI 主管和 C++ 程序员。我在他那里还顺手牵羊拿了一张与人乐队的首张专辑《遇事拘谨》(淘宝有售)，收获颇丰。
生活在杭州，生活在现场。西湖天地地图。
--EOF--
今天随公司团队活动蹭饭。和以往项目庆祝之类的饭局不同的是，这次是为了实习生团队毕业的庆祝。
看着朝气蓬勃的这群新鲜人，挺有感慨。自己也曾经和他们一样，毕业后满怀憧憬地杀入职场。只是到第一家单位报到的时候可没这些准同事这么幸运了。当时可没听说什么"职场融入"，也没有什么"馒头(Mentor)"，两眼一抹黑。公司的总经理当着我的面，称呼我的部门经理，"钱总"，害得我"钱总"、"钱总"的喊了好长时间。对我来说，一直都认为这是一个比较失败的职场开场白...
放眼看去，现在同事当中， 80 后越来越多。其实大多数 80 后和 70 后没啥差别的，自己当年的困惑他们肯定也有，能和他们多做点沟通、多做点分享还是比较有意思的事情。
遇到好多好学的家伙，每每和他们一聊就是半天。我开玩笑说，和刚毕业的新同事交流其实我挺怕的：最怕问问题我回答不上来；如果能回答的话，担心回答错了；回答错误不要紧，最怕回答错误被对方指出来。
--EOF--
在我国当前的语境下，"官僚"是不折不扣的贬义词，"技术官僚"这个词在某些时候能算中性词，根据维基百科，指各级机构中大量拥有专业背景的中高层阶层的俗称。本文所指的"技术官僚"毫无疑问是贬义词，指那些造出"国标馒头"或与之类似诡异事物的家伙。
在一家大型技术公司里或是大型项目中，如果说不要低估蠢人的力量，那么更应该防备技术官僚的负面作用。如何避免自己成为技术官僚?
第一,不要总说那些"正确的废话"。比如，同事发了一封邮件，详细的描述了一下某个技术细节的可行性，而技术官僚的回复类似： "这件事非常重要，非常有意义，感谢某某同事......" 大家都知道的重要事情，就不要总跑题去强调了。
第二, 不要把太多的精力耗费在开会上。尽管很多公司认为人是最宝贵的资源，却往往看不到人的最宝贵资源是时间。很多人之所以是技术官僚，就在于他们把会议当成了休息时间......
第三,不要任何事情都和竞争对手看齐。思考，不要盲从。有的时候，对方那么做，可能是不得以而为之，而你亦步亦趋，恰恰是没有创造力的体现......
可能技术官僚的特点还有好多，先从这三点克服吧。
以言说抵抗技术官僚，或避免自身成为技术官僚的一种有效方式是，寻找合适的时机，向老板及其同僚庄严宣布：你们都在放屁! (Hutuworm 对这段话有全部贡献)
--EOF--
继续我的学习笔记之旅。Flickr 的 DBA Dathan Pattishall 在前几天的 MySQL 大会上分享了 Scaling Heavy Concurrent Writes In Real Time (Record every Referral for Flickr Realtime) ，其中介绍了 Flickr Stats 的设计经验。国内好多 Web 站点其实也在设计类似的功能，只是不知道细节罢了。
字段 数据类型
Path_query Varchar(255) PK
Domain Varchar(50)
Owner Bigint
When Date
Object-ID Bigint
Object-Type Tinyint
Counts and stuff Various ints May be some keys
主键是字符串，开销太大。其他的索引如果做主键，也比较大。当表大小超过内存的时候，插入速度很慢，I/O 能力也上不来。
数据预处理，通过 CONV(SUBSTR(MD5(Url),0,16),16,10) 把 Path_query 修改为 64 位的 ID (8字节), 主键为 ID+Owner+object+object-type，这个统计信息很容易抽象到一个数据对象，这个索引的设计也在于此。
另外补充一点，利用 PHP 的 ip2long() 和 long2ip() 函数对 IP 地址作预处理，耗费的存储空间只为原来地 25%，这是个很有趣的技巧。
对于海量的数据，以一个礼拜为间隔，水平分割。按照不同的数据力度每周一个表，每年一个全局表，再加上一个汇总表。数据量越大，InnoDB 存储引擎针对字符串的索引浪费的空间就越大。单个查询的 I/O 也自然大了起来。
所有应用对 DB 的响应要求 是 300 毫秒。但高并发写入的时候响应时间就糟糕起来。Flickr 的 Java 牛人实现了 Referral 队列，每 4000 条做批量处理。这样 IO 拥塞的就解决掉了。
总体的服务器规模过去 介绍过，对专业版用户的数据是永久保留的，而普通用户则只保留几周，为节省空间，采用 MyISAM 引擎，当用户转为专业版时，迁移数据。
补充一下，抓取 URL 是用的 curl 。最后，这篇 PPT 在线观看。
--EOF--