我可以用 想问这个提供商靠谱吗，是不是有年头的？

%cpu 415.3 ?

#57 楼 @bhuztez 应该类似这个服务，我一般搜索好的图片就靠这个，http://www.tineye.com/

#59 楼 @bhuztez 我怎么没看到 Gibraltar

#55 楼 @bhuztez 谢谢！

找房的时候，中介一般要收费，所以一般都贴房子的照片，但不说在哪，我根据对城市的了解，再加上 google map 和 bing 的航空图，一般也能找出来。

不过你就比我更厉害，我要加强点功力了。

经常降价的： http://appshopper.com/mac/developer-tools/livereload

不过这个价格可以收了

#16 楼 @lgn21st 你说的的确在理，但当一个网站不是那么盈利的时候，有站长是宁愿网站打不开，也不愿为云存储或者 CDN 付大额流量费的，因为自己服务器是不限流量的。

那些变动大，不好管理，也是速度瓶颈的资源交给云存储或者 CDN 在一般情况下是有好处，费用在一般情况下也可以接受，但有这么一次 DDOS, 要是还持续几天没有觉察的话，真可能是一笔意外的开支。

所以网站要盈利是关键。有盈利就可以用高级的产品解放程序员和系统维护工程师。

#26 楼 @heliang7 五笔改为拼音，同感，

我大脑中的 PHP 很强悍，有 rails 进来时，直接攻击，现在有什么事，还是 php 第一时间告诉我该怎么做，ruby 多优雅与我无关，php 的笨方法告诉我，php 一定可以的。

本来想用 rails 在业余时间把一个 PHP 写的网站所有的代码重新用 Rails 写一遍，但现在内部决定为了节省开发时间直接上 discuz，好了，我又回去折腾顺手的 php 了。

现在国内用户对 discuz 的接受度相当高，是有点审美疲劳，但至少用户习惯了，很多功能不用开发了。UCenter 一站式搞定用户系统，比 OAuth 还是好用，现在钓鱼这么多，大家不太愿意在一个网站上用 qq, sina, facebook 登录。

#2 楼 @lgn21st 对 upyun 有个问题，如果我网站流量本来就很大，如果有人恶意 DDOS，那我为这些巨大的流量付费岂不会很惨。

#45 楼 @bhuztez 这么厉害，你快去中情局参加黑袋或黑箱计划吧，在这写 Web 太屈才了。

#4 楼 @shooter 这个靠谱： http://ruby-china.org/topics/12750

#23 楼 @bhuztez 怎么找的？图片有 GPS 信息吗？

#29 楼 @blacktulip 我看帖子标题就想到了你，可惜不在 UK，你还有前世小情人要照顾，不方便出远门吧。。

#33 楼 @whitecrow 好样的！

我最剧烈的运动是刷牙

#18 楼 @chinakr http://www.discuz.net/thread-991139-1-1.html http://www.discuz.net/thread-2279854-1-1.html 我刚才看了一下 .net 和 asp 的代码，好像比我想像的简单，其实就是把参数加密，以 post 的方式通知 ucenter。

重要的加密函数也有人做好了： https://github.com/eoecn/ucenter_authcode

同步也不是很难。比如 discuz 登录后，通知 ucenter，ucenter 再把参数以 get 的方式通知 rails 应用，这个链接可以自己定义，比如 http://www.domain.com/api/uc.rbget到的是action加参数，比如action=login&username=chinakr，这个链接，rails 就要实现这个 action，比如说设置 cookie，让用户登录。

rails 一般路由把 action=login&username=chinakr 换成目录方式了 http://www.domain.com/api/uc/login/chinakr， 而不是http://www.domain.com/api/uc.rb?action=login&username=chinakr 我水平不行，不知道这块怎么实现。

我现在没这个需求，以后可能有。真希望你们能做出来，放 github 上，造福大家，谢谢！

#11 楼 @chinakr 请问 PHP 和 Rails 的用户怎么打通的？谢谢

看你们有 BBS，应该是用 UCenter 吧？ 但 UCenter 没有官方的 Rails client 和 api，就算直接操作同样的用户表，那各 APP 同步登录，注销还是要自己处理了。

#3 楼 @kgen #4 楼 @blacktulip

目前想到的解决方案是美国做写服务器，中国，德国只读，读写分离，

美国作主服务器，中国，德国做从服务器，

这样中国德国读的速度会非常快，写的时候， 中国德国分别连美国，速度也有保证了。

好吧，7 楼成功删除了，有一分钟延时，现在 9 楼我删除了，多次刷新依然存在

#1 楼 @kingwkb 可以的，一个奇数，一个偶数 网速不行，数据量多的时候，它就死给我看，连接状态就不对了。

真想一刀切了，省心省事，但国内用户只能看不能记录点什么，也是问题。

#21 楼 @QueXuQ 设计师至少应该知道他的设计可以用 css 简单实现，还可以考虑到用 js 能将哪部分变成活动展示的。不然成了画家了。

设计师要是不懂一点前端的东西，那还是不好的，比如设计一些漂亮的导航按钮，五角星啦，菱形啦，前端就会痛苦死。原来网速不快的时候，设计师再来一张漂亮的背景图，上面再层叠很多元素，那前端可以去跳河了。。

#18 楼 @sevk 实验表明，30 公里以上其实就危险了，但 30 公里以下的时间不多。 再者，就算你 30 公里以下，比如说从辅路上主路，如果别人速度很快冲过来，也有问题。

所以最好养成习惯上车就系，这样不用纠结今天到底要不要系。

RULES FOR THE VIEW

1. Our markup should have meaning. We write templates using semantic HTML.

2. Our style sheets should handle presentation. We don’t use markup to style or use images when CSS will do.

3. Our templates should be free of client-side code. We unobtrusively attach behavior from our JavaScript files.

4. Our templates should be easy to read. We consistently indent correctly using spaces instead of tabs, type lines no longer than eighty characters, and extract complex logic to helpers and presenters.

5. Our templates should be easy to find. We use standard naming conventions and place them in the directory for the related resource (or the layout).

6. Our markup should be easy for the entire team to modify. We prefer rendering partials over generating markup from Ruby code.

7. Our technology choices should help, not hinder, the team. We use the templating language and tools that work best for all of us.

8. Our designs for the Web should work on a variety of devices and browsers. We build for the simplest interactions first and support progressive enhancement.

9. Our designs for email must work for a wide range of providers. We use HTML tables and images as necessary and always provide a plain-text alternative.

10. Our application should perform as well as it needs to, when it needs to. We implement the most elegant approach first, then we optimize when necessary.

楼下翻译？ :