Misc

我在博客上预留的三个广告位，目前却放了一个不在广告位上的广告。
这三个广告位是什么呢？在这里有详细介绍：http://www.neatstudio.com/show-142-1.shtml

主要是这三处：
1、BANNER
2、文章内页右侧
3、文章内页，文章结束的地方：目前是alimama的广告。。。

目前我在导航条下放了一个较大的广告，是个flash的。（还是flash容易控制宽高，而且变形不明显，HOHO），正好也算是38节（三八节），链接地址为：http://www.bestjia.com/special/women/

首页的左侧，也有我出售给Textlink的四个链接。每个链接因为我的PR高的关系，也有4刀一个月，如果PR高的网站，不妨可以尝试一下，PR3左右的就不要试了，PR3左右的网站好象很难卖得出链接。。。4以上的会好一点，点击 购买文字链。

以前，我们总是认为自己获取新信息新资料等等不够。总觉得自己看到的资料太少，信息获取渠道匮乏，可如今不对了，在这个信息爆炸的时代，你缺少的不是资料，而是缺少如何整理资料或者说如何在如海一样的资料中获取你想要的资料。100滴水，对你有用的可能只有5滴，那么你如何过滤到剩下的95滴呢？

看到有个人的博客这么认为信息过载：

* 很难从海量信息找到到合适的信息。
* 获取高质量的信息成本越来越高。
* 浪费的时间越来越多。比如点开一个新闻站点之后可能会不知不觉浪费很多时间来看新闻
* 心态越来越浮躁，很难静下心来去思考和吸引知识。网络上的文章都以快餐化为主，看整本书的人越来越少。
* 注意力非常容易就会分散。比如ＩＭ、邮件、RSS、Twitter、电话、短信、游戏等等。

而他的应对方法也很简单：

明确自己的目标，确定自己目前信息获取的关注范围。部分方向包括：学习研究（细分的方向在10种左右）、沟通方式、财务自由、国学、中医保健及养生、宏观经济学、厨艺、IT、外语等方面。
在每个系统中建立自己的知识框架，应用知识管理来不断完善，同时记录心得。
形成自己的GTD系统，不断完善和改进。
定期进行反馈和思考
把身边的信息源划分不同层次，明确轻重缓急
拿出固定时间来放松自己，缓解压力

他认为具体可以这样做：

1、对于遇到信息过载的人，说白了就是个人的目标不明确不具体，不清楚自己到底是需要什么信息，才会觉得信息越来越多。当你的目标明确之后，会发现高质量的信息还是很少。
2、强烈推荐学习快速阅读和思维导图，会发现带来的好处越出想象，同时节省大量时间
3、学习从无到有建设一个知识框架，并记录每一步的心得和反思
4、目前获得信息质量最好的办法还是书籍，网络上的信息质量越高，付出的时间成本就越大
5、尽可能少的去阅读新闻，新闻95%以上都对你的本人无效，同时会浪费大量时间
6、学习GTD，提高时间有效利用率
7、象IM、Twitter这类的东西能不用就用，浪费的时间会越出你的想象。象偷菜之类的网页游戏也少玩，或者想办法不玩。
8、你不是神不可能把一切做得完美，不要过于极端
9、学习利用手机来帮助自己
10、找出放松自己的办法，比如游戏、运动。
11、利用网络书店、社区、豆瓣、博客和朋友推荐的方式来得到书籍阅读清单，应用速读在书店和图书馆快速略读和路读来寻找自己对有帮助的书籍
12、学好英语，网络上很大部分的资料还是英文的
13、同时进行多任务操作，会分散你的注意力，要学习集中注意力，并练习延长集中的时间。
14、想办法建立或加入一个与你目标相同或相近的圈子，会对你有很大的帮助。
15、定期的反思和改进，非常重要，一定要养成这个习惯

不过我自己还是觉得对于时间的管理是最重要的。当然不能全部用来看书或者查资料。锻炼身体其实也很重要，没有身体，一切都是白搭。对于一些你认为以后可能会用到，而目前暂时用不到的，可以用一些软件记录下来。并用标签进行一些整理。相信以后有机会会用上吧。

上面3段转贴都来自于http://www.read.org.cn/html/978-how-do-i-deal-with-information-overload.html，各人的方法不一样，仅作参考

最近在网上不停的看到《全国政协委员建议关闭网吧 六成网友表示反对》以及相类似的新闻，甚至有黑客去黑了政协委员所在的公司网站。

颇有一番感慨，网吧这玩意，我从97年就开始知道，那时候的网吧还不能算是真正的网吧。或许就象陶教授说的是“游戏吧”，但我也在那段时间里熟悉了电脑的操作、使用，包括一些软件的安装、卸载，甚至是一些硬件的安装（偶尔还有尝试帮网吧老板的电脑超频）。或许这在现在看来是不可想像的事情，但在当时，一台MX166的普通电脑就要6、7000的时候，还真的需要网吧来学电脑。

现在的网吧，或者说是游戏吧。为什么就不需要了呢？由政府来开办公益性网吧？安排几个就业人员？我觉得不应该这样。毕竟孩子玩游戏是天性，关键在于家长怎么疏导。在上世纪90年代，没有网络，好多孩子还是沉迷游戏厅【我就是其中之一】。再说下去就又要谈网瘾了。其实想想，现在的孩子也真可怜，小时候的我们爬上爬下，玩来玩去，大人们管的也少。现在的小孩子，能去哪 里玩？到处是高楼大厦，出个门都得担心被车撞。我们小时候胡同里逛逛，附近的小孩也就都认识了。现在呢？铁门都拴起来了，锁也开始防盗了，天空不是蓝的，水也不是绿的，土地也成了水泥的。小孩还能干嘛？在家里，还不让上网，不让看电视。怎么过啊。。。

不过现在很多事情都是头痛医头，脚痛医脚的。实在没法治了，就直接切除了。

本文实在不算是发表意见，仅当争取多一些搜索关键字吧。因为写了一半不知道写啥了，再写下去怕被和谐。

大多数在win下面进行开发的人员，在做压力测试时，都是采用了apache自带的ab.exe进行测试的。工具虽然小，但也算强大。只是Ab的数据不是特别准确。
除此之一，还有一些工具可以做压力测试，如loadRunner,webbench等。现在我就做一点小小的介绍。。

格式： ./ab [options] [http://]hostname[:port]/path
参数：
-n requests Number of requests to perform
//在测试会话中所执行的请求个数。默认时，仅执行一个请求
-c concurrency Number of multiple requests to make
//一次产生的请求个数。默认是一次一个。
-t timelimit Seconds to max. wait for responses
//测试所进行的最大秒数。其内部隐含值是-n 50000。它可以使对服务器的测试限制在一个固定的总时间以内。默认时，没有时间限制。
-p postfile File containing data to POST
//包含了需要POST的数据的文件.
-T content-type Content-type header for POSTing
//POST数据所使用的Content-type头信息。
-v verbosity How much troubleshooting info to print
//设置显示信息的详细程度 - 4或更大值会显示头信息， 3或更大值可以显示响应代码(404, 200等), 2或更大值可以显示警告和其他信息。 -V 显示版本号并退出。
-w Print out results in HTML tables
//以HTML表的格式输出结果。默认时，它是白色背景的两列宽度的一张表。
-i Use HEAD instead of GET
// 执行HEAD请求，而不是GET。
-x attributes String to insert as table attributes
//
-y attributes String to insert as tr attributes
//
-z attributes String to insert as td or th attributes
//
-C attribute Add cookie, eg. 'Apache=1234. (repeatable)
//-C cookie-name=value 对请求附加一个Cookie:行。 其典型形式是name=value的一个参数对。此参数可以重复。
-H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
//-P proxy-auth-username:password 对一个中转代理提供BASIC认证信任。用户名和密码由一个:隔开，并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码)，此字符串都会被发送。
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-h Display usage information (this message)
//-attributes 设置 属性的字符串. 缺陷程序中有各种静态声明的固定长度的缓冲区。另外，对命令行参数、服务器的响应头和其他外部输入的解析也很简单，这可能会有不良后果。它没有完整地实现 HTTP/1.x; 仅接受某些'预想'的响应格式。 strstr(3)的频繁使用可能会带来性能问题，即, 你可能是在测试ab而不是服务器的性能。

参数很多,一般我们用 -c 和 -n 参数就可以了. 例如:

./ab -c 1000 -n 1000 http://127.0.0.1/index.php

这个表示同时处理1000个请求并运行1000次 index.php文件.
#/usr/local/xiaobai/apache2054/bin/ab -c 1000 -n 1000 http://127.0.0.1/index.html.zh-cn.gb2312
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests


Server Software: Apache/2.0.54
//平台apache 版本2.0.54
Server Hostname: 127.0.0.1
//服务器主机名
Server Port: 80
//服务器端口

Document Path: /index.html.zh-cn.gb2312
//测试的页面文档
Document Length: 1018 bytes
//文档大小

Concurrency Level: 1000
//并发数
Time taken for tests: 8.188731 seconds
//整个测试持续的时间
Complete requests: 1000
// 完成的请求数量
Failed requests: 0
//失败的请求数量
Write errors: 0

Total transferred: 1361581 bytes
//整个场景中的网络传输量
HTML transferred: 1055666 bytes
//整个场景中的HTML内容传输量
Requests per second: 122.12 [#/sec] (mean)
//大家最关心的指标之一，相当于 LR 中的 每秒事务数 ，后面括号中的 mean 表示这是一个平均值
Time per request: 8188.731 [ms] (mean)
//大家最关心的指标之二，相当于 LR 中的 平均事务响应时间 ，后面括号中的 mean 表示这是一个平均值
Time per request: 8.189 [ms] (mean, across all concurrent requests)
//每个请求实际运行时间的平均值
Transfer rate: 162.30 [Kbytes/sec] received
//平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题

Connection Times (ms)
min mean[+/-sd] median max
Connect: 4 646 1078.7 89 3291
Processing: 165 992 493.1 938 4712
Waiting: 118 934 480.6 882 4554
Total: 813 1638 1338.9 1093 7785
//网络上消耗的时间的分解，各项数据的具体算法还不是很清楚

Percentage of the requests served within a certain time (ms)
50% 1093
66% 1247
75% 1373
80% 1493
90% 4061
95% 4398
98% 5608
99% 7368
100% 7785 (longest request)
//整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于1093 毫秒，60％ 的用户响应时间小于1247 毫秒，最大的响应时间小于7785 毫秒

由于对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数

LoadRunner 对应用程序进行压力测试，以隔离并标识潜在的客户端、网络和服务器瓶颈。
通过 LoadRunner，可以在可控制的峰值负载条件下测试系统。要生成负载，LoadRunner 需要运行分布在网络中的数千个虚拟用户 (Vuser)。通过使用最少的硬件资源，这些 Vuser 提供一致的、可重复并可度量的负载，像实际用户一样使用您的应用程序。LoadRunner 深入的报告和图可以提供评估应用程序性能所需的信息。

LoadRunner 技术
使用 Mercury LoadRunner，可以创建场景，并在其中定义性能测试会话期间发生的事件。在场景中， LoadRunner 会在物理计算机上用虚拟用户（即 Vuser）代替真实用户。这些 Vuser 通过以可重复、可预测的方式模拟典型用户的操作，在系统上创建负载。假设您正在测试一个基于 Web 的旅行代理应用程序（用户可以通过它在线预订航班），并要确定多个用户同时执行相同的事务时，该应用程序将如何处理。使用 LoadRunner代替旅行代理，您可以创建具有 1000 个 Vuser 的场景，并且这些 Vuser 可以同时尝试在应用程序中预订航班。

测试过程
LoadRunner 测试过程由以下四个基本步骤组成：
➤ 步骤 1 — 创建脚本：捕获在您的应用程序中执行的典型最终用户业务流程。
➤ 步骤 2 — 设计场景：通过定义测试会话期间发生的事件，设置负载测试环境。
➤ 步骤 3 — 运行场景：运行、管理并监控负载测试。
➤ 步骤 4 — 分析结果：分析负载测试期间 LoadRunner 生成的性能数据。

LoadRunner 组件
测试过程的每个步骤均由一个 Mercury LoadRunner 组件执行。这些组件如下：
➤ Mercury 虚拟用户生成器 (VuGen) — 创建脚本
VuGen 通过录制应用程序中典型最终用户执行的操作来生成虚拟用户 (Vuser)。VuGen 将
这些操作录制到自动虚拟用户脚本中，以便作为负载测试的基础。
➤ Mercury LoadRunner Controller — 设计和运行场景
Controller 是用来创建、管理和监控负载测试的中央控制台。使用 Controller 可以运行用
来模拟真实用户执行的操作的脚本，并可以通过让多个 Vuser （虚拟用户）同时执行这些
操作来在系统中创建负载。
➤ Mercury Analysis — 分析场景
Mercury Analysis 提供包含深入的性能分析信息的图和报告。使用这些图和报告，可以标
识和确定应用程序中的瓶颈，并确定需要对系统进行哪些更改来提高系统性能。

webbench最多可以模拟3万个并发连接去测试网站的负载能力，个人感觉要比Apache自带的ab压力测试工具好，安装使用也特别方便。

1、适用系统：Linux

2、编译安装：

wget http://blog.s135.com/soft/linux/webbench/webbench-1.5.tar.gz
tar zxvf webbench-1.5.tar.gz
cd webbench-1.5
make && make install

3、使用：

webbench -c 500 -t 30 http://127.0.0.1/test.jpg
参数说明：-c表示并发数，-t表示时间(秒)

4、测试结果示例：

Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://127.0.0.1/test.jpg
500 clients, running 30 sec.

Speed=3230 pages/min, 11614212 bytes/sec.
Requests: 1615 susceed, 0 failed.

ab是最方便的。毕竟他直接内置。。。webbench需要安装在linux下，一般人还真难装。loadRunner太大了，几百兆的东西，而且，很多人还用不来。

所以我简要介绍一下。。

gouki这个词对我的影响其实是很大的。
从第一次玩街机游戏《street fighter》开始，就大致了解了SF的人物，也在一些【格斗天书】中发现了gouki(查看百度百科)这个名字。在那个没有拳皇的时代，gouki就是巅峰的代名词，于是乎，那时候就大言不惭的称呼自己为gouki了。

细细算来，以gouki为笔名、网名、其他的呢称等至今也有了15年左右了。其实已经很多年没有玩SF了，只是突然想怀念一下。再加上博客的作者又是以gouki为名，所以查看了一下搜索引擎，看看如果搜索gouki，能否搜到本站。

果然。。。。

这样的数字还是很让我开心的啦。HOHO

邓榕的笔记，值得一观。

突然发现自己好久没有定下心来看书了。不管是技术类书籍还是文学类，又或者管理类的书籍，真的好久没有定下心来看书了。以前还能做到每天晚上看半小时到一小时呢，现在。。。几个月没翻书了（电子书不算），更别挺看书笔记了。

原文地址为《Don’t make me think》笔记，内容如下

很多年前就看过《Don’t make me think》的第一版，第二版在书架上很久了，这两天才翻看。温故知新，笔记如下：

1. 某个东西越是需要投入大量时间（或者看起来会这样），它将来用到的可能性越小。
2. 可用性第一定律：别让我思考。
3. 我们使用web的第一个事实：我们不是阅读，而是扫描，一般会关注“与手头任务有关的”或者“当前或接下来的个人兴趣”或者“长久的兴趣，如免 费、美女等”这些文字和短语。（老邓注：所以，别老想着在首页上放一大段自吹自擂的话了，那是自恋）
4. 我们使用web的第二个事实：我们不作最佳选择，而是满意即可。
5. 我们使用web的第三个事实：我们不是追根究底，而是勉强应付，很少有人花时间读说明书，大家总是贸然前进勉强应付，一旦发现某个方法能够用，即 使很难用，也不愿意再主动去找另一种更好的方法，这不是智力问题，而是并不认为这个网站对自己有那么的重要。（老邓注：所以，别老想着用Flash去制作 一个“预订流程说明”了，那是单恋）。
6. 让页面不易理解的一个最大原因是视觉噪声，设计的时候可以先假定所有内容都是噪声，除非得到证明它不是。
7. 大多数页面上的大部分文字都不过是在占地方，因为没有人打算阅读它们。但它们确实在那儿，所以会暗示你可能需要阅读它们，这样常常使得页面看起来 难度更高了。去掉没有人看的文字能降低页面噪声，从而让有用的内容更突出，人们更加愿意阅读。（老邓注：这就是设计中常说的“少即是多”，加文字的时候需 要反问“是想给客户看的还是只是为了立此为证以便后面和客户理论？”）P34页有一个非常好的精简案例，精简幅度60%。
8. 如果你想为我提供选项来调整搜索的范围，在它有用的时候再提供给我——当我到达搜索结果页面，发现搜索全部内容得到的结果太多的时候，这时就需要 缩小搜索范围。
9. 共有区域的悲剧（The Tragedy of the Commons）。任何共享的资源（共有区域）都会因为过度使用而遭到破坏。（老邓注：这就是首页上为什么广告越来越多、内容越来越乱的原因）
10. 从焦点小组了解到的是你在设计网站之前就应该了解的，别把焦点小组和可用性测试弄混了。详细的区别见P100页。
11. 每轮可用性测试只测试三名用户，以保证尽快进行下一轮，多进行几轮。测试对象是谁并不重要，对于大部分网站而言，你只需要懂得上网基本知识的用户 就可以了。
12. 推荐屏幕录制软件Camtasia，它是TechSmith公司的产品，和SnagIt出于同一家公司。只需要300美元。再加1000美元，可 以买到该公司的另一个产品Morae，它允许观察者在另一台电脑上看到真实测试情况。
13. 测试中有两部分内容：理解测试，看看用户是否理解这个网站；任务测试，看看用户是怎么完成一些任务的。
14. P109-P113页是很值得一读的用户测试对话范例。
15. P115页，关于Kayak（皮划艇）问题。Kayak问题总是存在，因为有些含混之处总是没有简单的解决办法，比如“港澳台酒店”应该放在“国 内酒店”里还是“国际酒店”里，可能我们会觉得放到两个分类里。笔者的建议是一个项目最好只在一个地方存在，其他位置用链接“参见……”来标出。
16. 要抵制添加的冲动。当在测试时清楚地看到人们没有理解某些内容时，大部分人的第一反应是增加一些内容，例如一些注释或一些指导说明。而正确的解决 方案往往是去除某个（一些）让人混淆的内容，而不是增加另一些干扰。
17. 隐藏客户服务电话、运费、价格信息，会降低客户好感。隐藏电话的初衷是希望用户不打电话，通常这样做会降低用户的好感程度，而且他们找到号码并拨 打时会更恼火。另一方面，如果电话很容易看到，他们知道在需要的时候可以拨打，会让人们在网站上停留的时间更长，从而增加了他们自己解决问题的可能性。
18. 人们喜欢对网站的外观发表意见，但是几乎没有人会因为觉得它不够好看而离开。（老邓注：不过，根据《情感化设计》，更赏心悦目的网站，能增加用户 忍受度，使用户更加愿意探索）
19. 向用户询问不必要的信息可能产生三个后果：您得到的表单更少；您常常无法得到真实数据；您的网站形象下降。

--EOF--
因为这些东西涉及到用户体验，所以，我就复制了下来，偶尔看看也行。毕竟看不了书，看笔记也好的。笔记毕竟是读书时记录下来的要点。

【内容全是转载，觉得挺有意思。。。】
我想这让人难以置信，但是通过Twitter和电子邮件渠道蜂拥而来的报道表 明：许多参加程序员面试的求职者根本就不会编程，看看迈克·林最近的邮件就知道了：

《为啥程序员 都不会编程呢？》 这篇文章让我改变了面试的方式。以前面试我开始都以营造融洽气氛为主。正如你提到的，事实证明这种方式太耗费时间了，大多数应聘者根本就 不会技术。因此我以技术问题作为开头来面试应聘者，刚开始的时候，问题的难度是从容易逐渐变难。后来我发现反过来的话，甄别应聘者的速度会快些，即难的问 题先问（前提是难的问题必须属于“工作必备技能”一类的问题）。多数面试仍然会花上20分钟作用，因为回答和评估仍然需要花上一些时间。但是这对于之前” 先营造融洽气氛“的面试方式来说一个相当大的改进，而且还可以通过电话方式来完成。

在读了你的文章之 后，我开始通过电话，网络会议方式进行编程面试，甄别不会编程的应聘者（也就是大多数人）所需时间降到了15分钟左右。

我写那篇文章的时候时间还是2007年，三年后当我再次听人说应聘编程工作的绝大多数所谓的程序员竟 然不能写一小段程序时，我震惊了，但是也并没有完全出乎我的意料。需要清楚的是，难是一个相对的词汇——我们不是指那种复杂的有如Google计算机专业 研究生难度的面试题。我们给应聘者做的都是一些极其简单的题目，但是他们不会。这就相当于你想雇一位卡车司机，但是却发现90% 的应聘者竟然找不到油门和变速挡。

我也同意，这有些疯狂，但是这样的事情每天都在发生，而且这是我们这个行业在招人时常见的问题。

你需要通过这种简单的技术面试题来筛选掉这些伪程序员的大军。 我在前面提到过的，通过电话筛选是个明智的选择。不过通过网络方式来筛选效果要更好，并且更自然些。

我还是非常不习惯通过远程共享对方电脑桌面的方式与应聘者进行网络面试。我在网上搜索 了一下类似“纸笔”方式的编程面试的工具，但是没有收获。所以我做了一件所有有自尊心的程序员都会做的事情。我自己写了一个。伙计，花在这个程序上面 的精力很值！对每个应聘者的初期技术筛选所花的时间，我安排了15分钟。但是遗憾的时，我一般只需5～10分钟就能结束。如果他们能写10行简单的 代码，我就会给他们安排一次真正的面试。但是这种事情并不经常有，不过也好，至少我不会再浪费大量的时间了。

迈克加了一个声明，称他这个自制的编程测验工具并不是想秀一下他的编程能力如何。他需要一个这样的工具，所以他就写了一个——并且非常贴心的与大家分享了。 或许除了这个还有其他的工具；你们大多数人都使用什么在线工具来筛选程序员？

三年后，我仍然想知道：为什么一点都不会写程序的人都会冒出他们可以胜任程序员工作的念头来呢？ 的确，他们中有一些人会如愿以偿。但这也意味这个程序员这个行业的面试标准非常不合适。这是一种耻辱。它让每个在职的程序员蒙羞

水平差的程序还至少还可以接受教育来提高，而伪程序员不仅无药可就，而且还会让他周围 的同事自掉身价。这类人需要铲除，要做到这点就需要我们从最简单的技术编程测试做起，而这类测试也应该成为每程序员面试的一个组成部分。

本文来自东西 dongxi.net
来源： codinghorror | 作者：Jeff Atwood | 译者：neodreamer
声明：译者neodreamer拥有本文版权并授权东西网发布，非商业转载请参考东西网版权声明中的非商业用途转载版权说明；商业转载请联系东西网

再次看阿凡达，距离上次是一个月后的事了。
上次是在曹扬影城，普通3D版的，为了这个imax 3D，老婆是念叨了很久了，正好她去莱福士，看到这个加场，就买了票，最后一排的。
12点半的电影。上完课后回家睡了一个小时，11点半起床，打车去了莱福士。
15米高， 20米宽的屏幕看起来是爽。唯一不爽的是，眼镜好象有点差。（我去之前想了想，这么大的屏幕，我应该可以不用戴眼镜吧？果然，象我这种300度以内的眼镜男，不戴眼镜也看的很清楚）
效果嘛。。比普通的3D确实有改进，普通的3D看上去，就象浮在眼前，而imax的却有点身临其境 的感觉（当然这只是自己的看法，也可能每个人确实不一样）
这么大的屏幕，原来没注意的一些细节也能够完善的表现出来了。
只是午夜场看的太累。而且又是周四。

180的票加上打车费，一下子升级到了230。。。不过还算物有所值吧。虽然这个代价大了一点

在文章内容里加入了新的尝试，可以把页面分享至google reader;生成pdf;发送至wordpress,发送至live space。

看到很多网站有这个分享功能，我觉得我也是可以尝试一下。不知道是否有什么大用处，但或许能够有不一样的体验？
用官方的话来说，那就是：一个点击， 快速完成分享。 常在开心网或人人网看到朋友转贴的精采文章及图片吗? 【分享】就是背后的大功臣，一个强大的网页分享插件，让您将喜欢的博文、新闻等内容快速分享到社群网络上。

但其实，我还是认为这样会反而使得自己的用户在流失，不过，我这也算是一个尝试，而且bshare.cn上面有统计。所以我想试上三个月，看看有没有什么特别的用处。

分享按钮在哪里呢？是在文章的底部啦



上面的四个按钮的顺序也是我精心挑选的。点击更多则可以分享到其他网站。其中google reader用了你自己的google帐号，如果处于登录状态，可以直接使用。生成pdf则不需要任何帐号【比较适合收藏文章】其他两个也是需要在本站输入帐号，但其实是在bshare.cn的JS代码中输入，所以我不能保证是否会有什么密码XXX的问题。官方和弹出窗的提示窗上也都说了不会收集密码等信息。。。

今天上来看了看浏览量之后，发现一些问题，大量的分类充斥，让我的博客左侧 栏显得特别的长，因此，我对分类等做了调整，把一些文章较少的分类与较类似的分类进行整合，虽然整合后的数据还是很少，但毕竟比原来仅4、5篇那样的分类好多了。

其实，我还想把PHP再细分，或者再加一些分类，比如，我读别人的架构设计类的文章，这些放到哪里比较合适呢？慢慢先考虑。
sablog2远没有我想的那样优秀，暂时还是先用Sablog，不过，可能会往wordpress上面转。但文章也有点多，而且，原来的收录舍不得啊？
wordpress也可以自定义一些链接，估计可以用，show-%id-1.shtml，这样好象就差不多了。

值得思考的是文章中的代码，如果没有合适的代码编辑器，却不是特别敢转换。sablog2中的那个好象很简单只需要放在<pre>标签里就行了。有点心动。

慢慢来吧，删除了：smarty,Catchword,Learnenglish和android
smarty的新闻和学习资料太少了，就扔进了php分类里
catchword扔到了ideas里，learnenglish放进了literature中
android。。。本来想删除的，后来扔进了misc分类里，主要还是因为我已经有了另一个博客，专门用来记录android相关的资料以及我拍的照片等，它就是：http://g.52cd.net【手机记录生活】