这提议挺好的，也可以邀请几个人一起写作，商讨好大体的设定，做好基本条框，以免过于自由应该会很有意思。

ACG 和三次元色情不一样，有点属于擦边球的状态（相关法律少），不太过火还是可以的，关键部位打码什么的，不过站要放在国外。
而且由于擦边球的状态，周边产品比较多，而且比较精美，所以销路还是有保障吧。
另外，acgzone 还算比较正常了，sankakucomplex 才是真猛站，主站也是一堆广告，并且敏感内容几乎不打码，另有两个图库副站，一个真人、一个 ACG，广告数量不少，提供的图片也是各种高清无码。考虑到流量和储存空间的成本，这种方式能赚多少我就不说了……

游戏王后面的新增的内容多了很多，过于复杂就没再玩。

新年快乐，不过悲催的我在过年前几天和女朋友闹分手了 =_=
这一年是过得相当……冷清。

来个 JavaScript 版的：

while ( new Date().getFullYear() ) {
you.health = you.happy = you.wealth = Number.MAX_VALUE
}

微软推出 Office for Linux 不是为了给 Linux 厨准备的，他不关心 Linux 家庭用户用不用 Office。

最近一两年越来越多企业、政府单位从 Win 平台迁出，平台层面上微软做不了什么动作，比如安全性不可能突然大幅度提升，所以就从办公软件着手。

Office 里先不论 Word 在企业是否有合适的代替品，但 Excel 在会计方面是没有合适的代替品，功能太强大了。

此外，除了三大件，Office 还有 Outlook 等东西，要真成功影响了，拉个啥 Exchange 的也是一笔收入。

OpenOffice 什么的还是太菜了。

@no2x 客户端 hash 与否不影响客户端泄密的成功率，因为加密密码常见手法是 hash + salt，salt 相关的算法不被泄漏，即使拿到完整数据库也无从得知真实密码。而客户端不管是什么，都可能被截获，什甚至看源码就知道你是 md5 还是 sha1，现在 GPU 计算那么强大，算出对应的字符串成本还算低的。

我想过一个客户端加密方案，就是随机布局的虚拟键盘，而且键值也是随机的，比如点击 a 时不是返回 "a"，而是一个值的 key，服务器收到后，再转换成对应字符，这样的话要获取明文密码就只能获取点击时的字符（如截图）或算法。这样似乎不需要 SSL 也行（没真正部署过

@atsivsucks CSDN 「明文密码」泄漏和 HTTPS 并没有关系，前者泄漏是网站自身的，1）密码没混淆，2）服务器安全措施没做好；而 HTTPS 只是在用户的机器到服务器之间建立相对安全的通道，并没有解决前两个问题（一样会密码泄漏）。

在做好密码混淆、服务器防黑的情况下，用户在 HTTP 登录的时候密码被截获，这属于用户的问题，比如你在公共咖啡厅上网，任何一个网络服务都没有办法也不可能去为用户的上网环境负责，能做的只是像提供 SSL、安全令牌等「辅助服务」，但并不是「义务」。

BTW，CSDN 的不靠谱不是密码泄漏、不是没用 HTTPS，是明文储存，如果一个网站能把你的密码混淆到即使获得了，也不会影响到你别的帐号，就足够靠谱了，是不是 HTTPS 没关系。毕竟程序是人写、机器是人搭，漏洞难免。

PS：要密码却不用 SSL 的，比如 Google Reader 就不是强制 SSL 访问。

可惜对设计比较苦手。

其实开源项目的话，把部分或全部源码公布到 GitHub 之类的地方各方面会好一些吧，毕竟别人可以贡献代码。

第一次打开后，下划到了登录微博的界面，我不想登录，但是不管我怎么划，都死死地卡在那，无法回到天气界面。
按 Home 回到主屏幕后强退雨天再打开，结果不更新天气了，不管怎么点刷新，还是显示北京。
没法子，只能卸载。

[MarkdownEditing](https://github.com/ttscoff/MarkdownEditing)

Win: 网页版
Mac: Sparrow
iOS: Gmail.app

由于同时在用两个重要帐号，所以网页版那样的交互方式真心没效率。
Mail.app 和 Sparrow 之间，在整合方面 Sparrow 更胜一筹，所以就用这货，但因为倍收购的原因，如果 Google 不打算做，迟早会被抛弃。
iOS 是由于 Sparrow for iOS 突然傻了把我全部帐号清空了，所以就懒得用。

Win 平台没啥好用的，Thunderbird 真心烂，基于它的 Postbox 会好一些，虽然要 10 刀。所以我就用网页版 + iOS 了。

@jacy Data URI 有一个好处是 gzip，图片一般很难压缩，打比方，我有一个页面，分别用 Data URI 和普通 src 链接了同一张图，从 Chrome Developer Tools 观察到 HTML + Base64 大小为 27.87KB，gzip 后 20.43KB，图片是 17.29KB 和 17.57KB，传输时间平均值分别是 ~1.3s 和 ~1s。
虽然 base64 体积会比原文件稍大一点点，但是在 gzip 的影响下，一定尺寸内的文件还是建议能用 Data URI 就用，体验上会好一些：

- Data URI 可以省去 DNS lookup、connecting 和 waiting 的消耗（因为和包含它的文件共用了），消去了「比原文件稍大」的缺点；
- Data URI 不需要单独的请求也就意味着不需要进入请求队列，特别是对于某些需要尽快显示的图片来说，HTML 下载到它的位置就可以直接显示了。

除了会增大包含的文件的体积外，也有别的缺点：

- 不适合 lazy loading；
- 不适合图库类或需要交互的，比如 slideshow、fancybox。

@Frannk
@perrydu
@alexrezit 用 Mac 的话试试这个 http://chrisyip.im/data-uri-converter/

一个想法：把视频转换成 base64 字符串，分段储存；播放时组合起来，用 data URI 形式加载。

Milliseconds，只是最后三位，即毫秒，没显示而已（比如 Ruby 把毫秒放在小数点后，转整数就会砍掉），只保留了年月日时分秒信息。对于毫秒也属于整数一部分的语言（如 JavaScript），要转换成 Date 对象，只需乘以 1000。
用 milliseconds 做时间的单位，好处是只需要处理数字（比如日期大小、比如距今多少天），并且省去时区的隐患：得出结果后再转时区。

苹果对 iCloud 的定位不是开放性服务啊。
苹果的东西是自己生态内的，只供应给自家的东西，这并不是「自大」，是「经营策略」。
BTW，邮箱应该是可以通过 POP3/IMAP 用别的客户端收发，Calendar、Reminder 之类就不行，iCloud 的储存空间也不行（通过生态内的 app 可以处理，比如 OmniFocus、Things）。
如果不同平台的设备多，Gmail、MS Exchange 是最佳的选择。

@iwinux 给 Firefox、Chrome 用的话，没必要用 jQuery 吧……

先后在两家非知名专业机构做的域名贩卖商（比如 999.cc、paomi 之类的）里买过域名，都不愉快，最悲催的是有些 VPN 的 DNS 不能顺利解析贩卖商自家的 namerserver，还不能改！尼玛当时是挂 Tumblr 上，挂不挂 VPN 都上不了自己的域名，悲催死了！
后来心一横，换了个 name.com 能注册的域名。
所以价格差不多的，还是找专业的域名贩子（name.com、godaddy）比较好，不过听说 godaddy.com 会耍小动作，比如把你心仪的好域名抢注让你高价买什么的……只是这家的产品很多，优惠码也很多。
.im 的话，name.com 并不贵，而且有 auto renew，绑了信用卡就不必担心忘了续费过期，另外还有 whois privacy，记得要和域名一起进购物车再用免费码，否则没用，我就忘了把它放购物车就直接打了免费码，虽然显示验证通过，但购买后是没有 whois privacy，也不知道怎么再加上。