#7 楼 @leekelby

http://no320cdn.b0.upaiyun.com/demo/sampleupyun.html#

#2 楼 @hz_qiuyuanxin 主要是 js 和 css 的东西，ruby 只是封装了一个命令行工具，目前还不好意思放出源码呢，哈哈

#3 楼 @huacnlee 哈哈，我对字体研究太少了，求推荐字体~~

#1 楼 @iBachue 就是把 markdown 转成 html 中得，可以 git 到本地，只要一个命令，即可把 md 文件生成上面的功能。目前还没有集成编辑器，用户的成本只要会 md

性能

写个 gem 版的吧，不然在 ruby 社区会被鄙视死的，哈哈

mqtt

是个好东西

看 xmppframework 去吧

dive to py

学 ios 还不如 ruby 呢，少年

#1 楼 @nightire 什么书，多少钱？

不确定有木有时间啊，手头有 angularjs 和 ionicframework 的东东

#2 楼 @kgen 建议有这样的经历，自己切身感受才能铭记于心的

#3 楼 @Rei 让他看看 java 的 hibernate，他就懂了

还不错啦

又是用一个云服务，然后 rm 做界面的，一个小时也足够了，话说 oc 也可以的

#11 楼 @Martin91 我是在 2.1 下面测试的，可能 2.0 下面有问题，明天修复，早点睡

#8 楼 @Martin91 可以参考 ruby-china 的 wiki

• https://ruby-china.org/wiki/how_to_create_a_gem
• https://ruby-china.org/wiki/building-a-command-line-tool-with-optionparser

#5 楼 @Martin91 写 gem 还是比较简单的~~建议你动手试试，15 分钟搞定一个

#5 楼 @Martin91 这东西不方便写简介的，哈哈，宅男利器

#3 楼 @Martin91 嗯，自己写的 gem，使用 ruby best practice 里的东西重构的

#1 楼 @Martin91 你是一个非常善良的人~~~哈哈，这是个下载图片的 gem

之前想改这个问题，后来忘了。。。。

21 克

#9 楼 @fredwu

1. 基于 Scrum 和 Kanban 的 agile，但我们更要求的是“常识”，而并非按部就班的按照所谓的“agile”理念来行事。中心思想——不要人云亦云的盲目追随 agile。

好东西

1. 我们用 TargetProcess 来管理项目。之前用了很久的 PivotalTracker，但我们项目的复杂度已经超越了 PivotalTracker 的能力领域。中心思想——使用一个能提高团队效率的工具非常重要。

好东西

1. 保护团队，用最硬的盾牌来抵挡公司老总和上层管理的侵入。比如，我们公司目前三个团队，我们团队是唯一一个从未加班过的团队。

尽力，但有的时候力有不逮

1. 为团队谋求更多的利益——比方说水果零食、不定期的团队午餐聚会、等等之类的。一个 happy 的团队才会有效率。

做到了，而且建立了每天中午轮流由一个人买好吃（自愿，大部分都是吃了别人的，自己也会分享的）的习惯，大家都很开心

1. 通过 code review 和其他媒介严格把控代码质量。大到 implementation 方式，小到一个空格——code review 时一定要对事不对人的指出更正与改进的地方。慢慢的让团队里的所有成员都不自觉的撰写出质量相当的代码。

做到了，其实严谨让容易建立威信

1. 鼓励团队成员互相 review 代码，而并不是把 review 的重任扛在自己一个人的肩上。鼓励时不时的 pairing。

不只是互相review，更重要的是互助，不然啥都找领导会痛苦死

1. 学会“let go”，而并非一意孤行的要求团队成员按照自己的方式来实现项目的内容。

放手，相信团队成员，更容易有惊喜，留出20%以上的功能给团队成员自由畅想

1. 在“上层”面前尽量褒奖团队成员的成果。

必须护住，孩子都是要背后打，当外人面一定要保护好

1. 有过错自己担当，千万不能说“哦，那是因为某某某……”。

包容一些，比如看到一些小错，也不要说，很多人自己心里都清除的，你给他的自由，他给好的代码

1. 把控时间——无论是开会，讨论，或是 standup 时，提醒成员也提醒自己，不要跑题，不要无谓的浪费时间徘徊在没有结论的议题上。

开会应该像女生的裙子，越短越好，当然前提是沟通清楚

1. 每 6-8 周我会分别与团队每个成员进行一对一的 casual chat。

我一般是年后或者假日后做，放开了，听各种抱怨和期望，建议等，偶尔也要解答一下疑惑

1. 学会聆听。

做领导的基本功课，即使你不懂，也要听，很多时候，他讲完后自己就发现问题了，如果你不听，互相就没有信任感，以后什么事儿都不愿和你说

1. 开会，甚至是平常，有 action points 一定要记下，并设定好时间去实行。实行完毕后告知团队。

言必行，行必果，以身作则

1. 合理分工。尽量避免系统里的东西只有团队中的某一个成员熟悉。

这个其实最难，这时候知识面宽广就显得非常重要了，然后按照每个人的特点分配，孙子说：庙算多者胜

1. 时刻观察代码的综合质量与走向，自己必须清楚代码的大方向与架构。

心中有数，大事儿小事都要有数，另外坐在一起，在持续交付中做好code review

greate

why not use Varnish？某些场景

这个必须顶啊，很帅，值得拥有

#1 楼 @nightire 广告帖么