#7 楼 @mrpasserby 几千几万还是不难的。几千万就有点过火了。
其实还是出国好,眼界会开阔很多。排名 50 内的 CS 已经很好了,你让我们这种排名 100+ 的 CS 怎么活啊。
可以考虑进 MySQL 的命令行看一眼 show processlist
。
挂载磁盘和原生磁盘相比还是有差距。
我在 AWS 上用他家的 EBS SSD 磁盘,感觉慢得不行,根本不像是 SSD 应该有的速度。
(相比之前开的独服上的 SSD 那性能简直天差地别)
另外很多云都有 IOPS 限制,比如 AWS 上有一个 BurstIOPS 给你用,Burst 用完了以后就开始限速读写,慢慢恢复水桶令牌。
你可以看看他们家有没有类似的问题。
说实话这点基本看不出什么。 一般来说有几个点可以看,一个是数据库压力(可以看看进程列表),一个是 Unicorn 进程,一个是磁盘响应速度。 另外还可以看看是不是真的是压测导致的问题而不是偶然的两个事件正好撞在一起了。
What? 1000 个请求就挂了?这也太脆了吧我压测都是几千几万的请求上的。
不过这个磁盘空间1T(挂载)
的挂载两字感觉有点慌啊?
#10 楼 @bird_on_rails 比如说按照 Java 的风格你会这么写
result = new Array
for (d in data) { func1(); if(!func2()) continue; func3(); result.push(func4()) }
按照函数式风格的话
result = data.map(&:func1).select(&:func2).map(&:func3).map(&:func4)
其实可以看看 Haskell。学完以后回头就能写出浓郁函数式风味的 Ruby 代码了。(拖
#4 楼 @xiaoping_rubyist 一般来说从 Rails 3 开始玩起的都不会知道 Finder 语法。我 Rails 4 写了一年多了,到了新公司一票的 Rails 1 才知道 Finder 这东西。
现在公司里的项目就在享受问题一 + 二+三。 没有问题四纯粹是因为我们连 Gem 都还没用上,还在用 Plugin 模型。
Finder 语法淘汰了。来自 Rails 1.x 的搜索语法。
易语言不太适合大型软件开发。以前曾经试过,后来还是老老实实换用 C# 了。
两个项目共用一个 80 端口,就像你和隔壁老王共用一张床一样。
GitHubFlow 和 GitFlow 其实是很类似的结构,唯一差别就是 Fork 出来的 Branch 是在自己而不是公共的 Repo 里。 GitFlow 简单说就是做得有点过了。SmartGit 现在内置的 GitFlow 自带一个简化版,就是只使用 Feature Branch,轻量了很多,用起来也非常舒服。 另外这种模型本身也适合较短的开发周期,一个 Feature 应该在几天或者一两周内完成。持续集成测试保证了每次 merge 的时候都是可用的。对于 Ruby 这种周期短又有测试覆盖的环境来说非常合适。但是对于其他一些环境来说可能就不那么合适了。
<%= @list.each do |one|%>
# ↑
# |-> 等号就是输出哦
# ↓
<%= @map[one].each do |en, zh| %>
受教育较高且无女朋友无约炮无三观不正情况。
你说的是清华少年班的小朋友吧? 现实世界有这种情况的?
#10 楼 @xianshui_007 改完以后好看多了 :thumbsup:
有 Ruby, Java,PHP, Python 等语言开发经验的优先考虑
标点符号敢不敢写写好呢。隐约透露出一股不太认真的 feel。
https://www.codeschool.com/paths/ruby Rails Testing for Zombies Testing with RSpec
网上可能会有别人盗版的视频。我当年是看这套教材学的。
写 Java?弄个百人团队先……
这 vagrant 不就是 ubuntu 么……
#12 楼 @suxiaohun 个人偏向 rspec。平时基本只做集成测试,对于模块才做单元测试。
测试是为未来节约时间。每次程序升级、功能增加修改、代码重构,都需要测试。 你可以人肉测试,但是这样需要招聘很多人,写很多人肉测试用例,然后还会有很大概率漏掉 Bug。 自动化测试可以给你省下几万几十万的钞票,并提供更一致的测试结果。
应聘了 PHP 程序员职位,进去以后被告知全面转向 Rails 了。