Peter (Peter) · 回帖

大家平时会做什么极限运动？ at 2013年07月24日

我最剧烈的运动是刷牙

#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 同步登录，注销还是要自己处理了。

问个数据库同步问题 at 2013年07月20日

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

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

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

有没发现最近的跑步贴很火 at 2013年07月19日

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

问个数据库同步问题 at 2013年07月19日

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

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

什么叫网页射击师？ at 2013年07月18日

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

什么叫网页射击师？ at 2013年07月18日

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

你系安全带吗 at 2013年07月17日

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

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

10 rules for Rails view at 2013年07月16日

RULES FOR THE VIEW

Our markup should have meaning. We write templates using semantic HTML.
Our style sheets should handle presentation. We don’t use markup to style or use images when CSS will do.
Our templates should be free of client-side code. We unobtrusively attach behavior from our JavaScript files.
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.
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).
Our markup should be easy for the entire team to modify. We prefer rendering partials over generating markup from Ruby code.
Our technology choices should help, not hinder, the team. We use the templating language and tools that work best for all of us.
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.
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.
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.