#8 楼 @lgn21st 可以用 dns 的方式验证，推荐这个脚本 通过 DNS 验证方式获取 lets-encrypt 证书的快速脚本

一只没搞明白 Phoenix 为什么要一个 view 还要一个 Template

#12 楼 @hooopo 还有 @search

其实可以做到对于 搜索引擎和移动设备 在 server 端渲染，桌面设备在浏览器端渲染。 这样就没什么问题了

小区里面的别墅啊？

#1 楼 @lgn21st #3 楼 @search 三楼的用户名

#15 楼 @fsword #9 楼 @virgil 你们应该看下这里 http://huaban.com/boards/13712493/

cooool ! 做出来送嘉宾不错啊

妹子，还有更危险的呢 ...

有妹子》支持

还没来得及听， @xdite 姐的 gitst 里面有提到键盘啊： https://gist.github.com/xdite/3075660

#49 楼 @lgn21st 哈哈，这也并非是我的需求，我最近工作上遇到了这个问题，也用的是 dnspod 免费版.。估计 DNSPod 免费版实际上还不够智能，只是简单的根据用户网络解析到对应 IP，还没达到智能解析。

#42 楼 @lgn21st 速度倒没什么影响，但连接到 ruby-china 没有达到最优啊，呵呵。我有个疑问，对于 dns 服务器来说，响应用户请求到最快的 ip 上，但实际上用户连接目标域名却没有达到最优，一般这中情况是怎么解决的呢？

#39 楼 @lgn21st 我的网络是有线通，我 ping ruby-china.org 时 dns 解析到了 101.69.180.25，但 ping 122.226.207.19响应更快点 (虽然差距不是很大，见 #33 楼)，怎么破？

$~ ping ruby-china.org
PING ruby-china.org (101.69.180.25): 56 data bytes
64 bytes from 101.69.180.25: icmp_seq=0 ttl=45 time=56.460 ms
64 bytes from 101.69.180.25: icmp_seq=1 ttl=45 time=74.709 ms
64 bytes from 101.69.180.25: icmp_seq=2 ttl=45 time=58.745 ms
64 bytes from 101.69.180.25: icmp_seq=3 ttl=45 time=67.184 ms
64 bytes from 101.69.180.25: icmp_seq=4 ttl=45 time=56.005 ms
64 bytes from 101.69.180.25: icmp_seq=5 ttl=45 time=54.838 ms
64 bytes from 101.69.180.25: icmp_seq=6 ttl=45 time=56.008 ms
64 bytes from 101.69.180.25: icmp_seq=7 ttl=45 time=57.579 ms
^C
--- ruby-china.org ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 54.838/60.191/74.709/6.578 ms

$~ ping 122.226.207.19
PING 122.226.207.19 (122.226.207.19): 56 data bytes
64 bytes from 122.226.207.19: icmp_seq=0 ttl=49 time=22.895 ms
64 bytes from 122.226.207.19: icmp_seq=1 ttl=49 time=25.034 ms
64 bytes from 122.226.207.19: icmp_seq=2 ttl=49 time=17.409 ms
64 bytes from 122.226.207.19: icmp_seq=3 ttl=49 time=18.186 ms
64 bytes from 122.226.207.19: icmp_seq=4 ttl=49 time=22.278 ms
64 bytes from 122.226.207.19: icmp_seq=5 ttl=49 time=20.734 ms
64 bytes from 122.226.207.19: icmp_seq=6 ttl=49 time=19.433 ms
64 bytes from 122.226.207.19: icmp_seq=7 ttl=49 time=20.212 ms
^C
--- 122.226.207.19 ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 17.409/20.773/25.034/2.373 ms

这让我如何是好

google 的这个 chart api 可以 demo： https://chart.googleapis.com/chart?cht=qr&chs=200x200&choe=UTF-8&chld=L|4&chl=ruby-china.org 介绍: https://developers.google.com/chart/infographics/docs/qr_codes#overview

#7 楼 @lgn21st 恭喜

不错

cool

点 立刻购买 又回到这个帖子了，貌似 apple 的这个 bug 一直存在哈

#27 楼 @huacnlee 好方法

当时填写的招行的卡，马上登陆招行网站，把这张卡的额度设为 1 元，同时申请换卡了

目测将要变成 show 装备的了

没付费，很费时间，没完了

一早在新 mac 上安装环境，发现有 ssl 错误，一查，果然是证书过期了

谢谢各位，解决了，果然是 bundle 的原因。

#22 楼 @thisiskun #12 楼 @hisea 我发现是在这里删除了当前生成的 release

*** [deploy:update_code] rolling back
  * executing "rm -rf /home/deployer/apps/tick/releases/20130312091522; true"

我一边部署，以便观察/home/deployer/apps/tick/releases/目录，发现刚开始生成了 20130312091522 这个 release. 之后就发现被删除了，终端里面看见输出信息里面的上面一段，有删除操作。 服务器环境是没问题的，手动取部署后通过浏览器正常访问。 难道我部署的步骤有问题吗？ 我是这样部署操作的：

1. cap deploy:setup
2. 登录服务器取修改 apps/tick/shared/config/database.yml 文件，设置为服务商对应数据库的信息，同时登录 mysql，创建 production 数据库
3. 执行 cap deploy ,然后就报 #6 楼 的错误

#20 楼 @thisiskun 但是我 clone 一份在那台服务机上没问题啊， ruby -v 也输出我安装的 ruby 版本

#16 楼 @xiaoronglv 你刚才的问题解决了吗？