同上网本
用的是哪个版本 rails 啊,按照文档的话,flash.now
应该是满足需求的
Sets a flash that will not be available to the next action, only to the current.
git 录屏是用的 LiceCap
当 install 了一个 gem 之后,会将其源代码 clone 到指定地方,方便以后查阅、研究
感觉这个有点多此一举,本来已经下载一份源码了,还要另外 clone 一份到指定地方。
针对“方便以后查阅、研究”,我觉得这是个重复造轮子的事情了,事实上,bundler 本来就提供了 bundle open [gemname]
命令用于直接打开项目中 Gemfile.lock
文件指定的 gem 的源码。
如果你的当前目录并没有 Gemfile.lock 文件,但是想直接查看某个安装的 gem 的源码,也非常简单,安装一个 qwandry
就行了:
而以上不管哪种方式,只需要配置好一个 EDITOR
环境变量就好了
必须顶一个!
赞,目前已向多位朋友安利过云梯!
对方给了 speedtest 的数据
I ran some tests from our Tokyo2 datacenter to China Telecom (which is the ISP you most recently logged in from), and I can verify that bandwidth to Guangzhou does seem this bad:
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Linode (139.162.65.36)...
Hosted by China Telecom (Shanghai) [1762.85 km]: 315.817 ms
Testing download speed........................................
Download: 103.76 Mbits/s
Testing upload speed..................................................
Upload: 2.13 Mbits/s
此处省略其他类似的测试报告 * n
最后的结论:
That being said, I do not believe this is an issue with our end of the network as we are provider much better bandwidth to other parts of China while still using the same upstream provider. I would recommend reaching out to your ISP for further assistance.
今天又给 Linode 提了 traceroute 报告跟下载测试的报告,然而他们给我的答复的大概意思就是“我们测试过了,在我们这边是好的啊,不是我们的网络问题”。
之前给 Support 提了 ticket,得到的答复是,东京 1 不能升,然后,因为东京 1 不支持 $5 的价格,所以原来用着 Linode 1024 的需要继续支付每月 $10 的费用,他们极力推荐你迁到东京 2。但是测试过,速度感人地不行。。。
除非遇到了无法解决的瓶颈而别的工具刚好又解决了,否则就用自己熟悉的工具就好,不必纠结工具问题。
只要你能到达梦想的彼岸,没人在意你划的是什么破船。
工程领域也如此。
小标题反映文字组织能力。。。
就知道你会第一时间升级
广州的推荐老东家 @leondu 的团队,哈哈!
这个没有个标准或者参考的,但是秒级肯定是不对劲的,特别是简单项目来说,几十毫秒到几百毫秒比较正常吧
@YingJie coding IDE 上不管请求多少遍,都是这个结果吗?
也有可能是因为他起的是开发环境,这是首次请求的吧
照我的尿性现在一定是沉迷网游或者各种风月场所
听起来好像是很美好的小康生活
看来你们都用的假的 Linode 了,哈哈
#11 楼 @hz_qiuyuanxin 早就猜到了
#9 楼 @hz_qiuyuanxin 嘚瑟 ╭(╯^╰)╮
是 slim
不是 skim
吧。
slim 里缺省的标签就是 div
,如果 div
标签没有任何属性时,就必须显式写上 div
啊。
.first id='view'
/ 等价于:
div.first id='view'
/ 上面这种显式的写法也是符合语法的
这个没有死标准,看关联的数据后续还有没有保留的必要,如果没有,就可以直接 dependent: :destroy
;如果有,看要不要保留数据里的外键(比如可能用于后续的数据统计分析需要),如果有,就连 :dependent
都不用声明了,所关联数据就不会动了,如果没有,可以声明 dependent: :nullify
将外键置空。
举个例子吧,比如我有一个 CMS 系统,实体有 Page(网页)、Picture(网页上的照片)以及 Visit(网页访问,记录来访用户信息以及受访网页)。一个网页上会有多个照片,同时也会有多个访问记录。一般来说,如果我删除了网页,那么原来网页上的照片也没有留着的意义了,所以我们期待一旦删了网页,也要清除网页上的照片。另一方面,尽管我删除了网页,但是我仍然想要知道整个站点历史访问量情况,包括 PV(要记得访问的是哪个 page,也就是 page_id 外键有必要保留,不能被置空)、UV 等,那么访问记录的数据我是不想随着网页被删而同时被清除的,那么这个业务的代码就是:
class Page < ActiveRecord::Base
has_many :pictures, dependent: :destroy
has_many :visits # 关联数据不声明 dependent,将不会被自动删除
end
事实上,我能想到的关联数据不清除的场景,基本也都是一些有审计用途的数据了。
:D 我之前也写了个类似的帖子,还没有看过的同志们欢迎进入传送门:周末到了,来段代码压压惊