Ruby 的话,我推荐 http://lotusrb.org/ 还有 http://rom-rb.org/ 。虽然这两个项目都有一定的规模,但是每个 component 都封装的很好,可以一个一个拆开来观摩。
JavaScript 的话,我近期接触的不多所以不太了解……
在工作中遇到中间插入的事情,你是如何处理的?
我目前在带领的团队之一就是有这种情况,我们统称这些需求为 BAU (Business As Usual)。我们对这些需求的处理方式是这样的:
综合这三点:我们部门的所有团队(一个四个产品团队,一个部署工程团队)上的开发人员,除非是担任 squid 或相似的角色,其他程序员都不会被杂事打扰到。
如何看待事情的职责分明。
这个我觉得是企业文化吧,或者是团队文化。要看公司和团队的 leadership 怎样去鼓舞大家了。在我们公司,我们一直在大力的提倡所有人都要 proactive —— 也就是说,在自己能力范围内可以解决的事情,尽量想办法解决,而不是坐着等别人来。通常我都会和我的团队成员,还有我的直系下属谈心,拉近距离,然后用比较“软”的方式去鼓励他们。
当有人“屡教不改”时,就是一对一谈心给 feedback 的时候了。如果在招聘的时候招的都是比较优秀的人才的话,绝大部分人都是会警惕自己提高自己的。
如何提高自己的技能树
这个不管是程序员也好,或者是像我目前的职位——几乎没有什么时间编程,都是可以挤出时间来提高自己的。就比方说,我们部门有一个三人的部署工程团队来替四个产品开发团队提供部署和自动化方面的技术支持,公司也有一整个团队给公司所有团队提供部署的工具。但在日常的产品开发中,时常还是会需要一些小工具让自己的工作变得更有效,这时候,就可以自己找时间来“把玩”了。我最近期的 Amaze Hands 就是通过一半工作的时间,一半自己的时间,拼凑出来的。若干年前,我在带领一个主要是 PHP 的团队的时候,也是凑时间出来自己用 ruby 写小工具。
时间和事业线一样,挤挤总是会有的。-__,-
#11 楼 @tianzhen 我反而觉得国内相对都会落后几年。就好比 ruby,在澳洲 ruby 挺早就“盛行”起来了,ruby 社区早年许多个开源的项目都是澳洲的程序员开发的,比如 Formtastic, Machinist 和 Thinking Sphinx 等。Java 和 .NET 在哪儿都是占大头所以这个和其他地方一样。对前端的需求相比而言比对后端的需求要少,因为很多小公司直接都是招 full stack 的,但前端的职业也有不少,工资可能相对没有后端的多就是了。
#12 楼 @pathbox 其实没有什么捷径——多花时间多花心思。别人出去约会玩耍的时候,如果你把这些时间用来开发程序,日积月累,就慢慢可以超过其他人了。当然了,适合的学习的方式也很重要,但每个人都不同。就我本身而言,看大量的开源项目,以及自己参与开发大量的开源项目,从中获益匪浅。
#13 楼 @jimrokliu 从流量角度而言的确是。所以澳洲大部分公司相对不需要太多处理高负载高性能方面的人才。
#1 楼 @blacktulip 心得说不上,因为我也有拖延症。但我一般:工作上的东西我都有用 todo 来管理(我用 Todoist),每天应该完成的事情通常都当天完成。对于自己本身想要达到的目标,我前阵子开始尝试用 Trello 来管理。
#2 楼 @springwq 订阅 Ruby Weekly,多看开源项目。等对 ruby 的认知到了可以自己写程序的时候,多写一些自己可以用得到的小工具。等用熟练后,慢慢可以开始参与开源项目的开发。
#3 楼 @fighterleslie 现在是 job seeker 的市场,供不应求——前提是优秀的程序员供不应求。基本上稍微有点工作经验的 ruby 程序员全部都有工作了,很多公司(包括我们公司在内)从一两年前开始就迫不得已的开始寻求有经验的 Java / .NET / 其他语言的程序员,开始培养他们写 ruby。
#4 楼 @knwang Brisbane 我不太了解,墨尔本和悉尼都有规模相对较大的公司,所以对初级程序员的友好度还算高。比方说我们公司,虽然其他部门仍然在招高级程序员,但我所在的部门在最近的半年里已经招了三位初级的程序员了。
#7 楼 @winnie 刚来的时候的确是,不过那也是十多年前了,环境不同。现在的话还好,习惯了这边的生活节奏。而且现在不少商店也营业到挺晚的——当然,和国内的大城市还是不能比的。
如果用户资料的 Location 里有多个的话(比如我的是Melbourne, Australia (Shanghai, China)
,只有其中一个被识别。:P
半年前办公室是长这个样子的,现在多了很多白板
考虑了好几天... 终于下手投稿了... XD
除了 service 外,还可以细分出 decorator, presenter 之类的。
我之前带队的项目的数据:
+----------------------+-------+-------+---------+---------+-----+-------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Decorators | 530 | 441 | 18 | 85 | 4 | 3 |
| Finance | 1593 | 1372 | 52 | 204 | 3 | 4 |
| Presenters | 1608 | 1464 | 68 | 78 | 1 | 16 |
| Queries | 32 | 27 | 1 | 5 | 5 | 3 |
| Representers | 1435 | 1138 | 5 | 170 | 34 | 4 |
| Services | 3225 | 2589 | 75 | 333 | 4 | 5 |
| Uploaders | 54 | 12 | 1 | 3 | 3 | 2 |
| Validators | 486 | 430 | 23 | 54 | 2 | 5 |
| Controllers | 1612 | 1298 | 55 | 165 | 3 | 5 |
| Helpers | 224 | 184 | 0 | 40 | 0 | 2 |
| Models | 4057 | 2204 | 78 | 210 | 2 | 8 |
| Mailers | 12 | 11 | 1 | 1 | 1 | 9 |
| Javascripts | 789 | 590 | 2 | 176 | 88 | 1 |
| Libraries | 1352 | 1157 | 42 | 132 | 3 | 6 |
| Controller specs | 1135 | 918 | 0 | 2 | 0 | 457 |
| Decorator specs | 640 | 502 | 0 | 0 | 0 | 0 |
| Finance specs | 1298 | 1012 | 0 | 0 | 0 | 0 |
| Helper specs | 44 | 36 | 0 | 0 | 0 | 0 |
| Lib specs | 83 | 67 | 0 | 0 | 0 | 0 |
| Mailer specs | 30 | 22 | 0 | 0 | 0 | 0 |
| Model specs | 2847 | 1477 | 4 | 4 | 1 | 367 |
| Presenter specs | 607 | 459 | 1 | 0 | 0 | 0 |
| Representer specs | 1327 | 1030 | 0 | 0 | 0 | 0 |
| Routing specs | 13 | 11 | 0 | 0 | 0 | 0 |
| Service specs | 2528 | 1903 | 2 | 8 | 4 | 235 |
| Validator specs | 691 | 527 | 0 | 2 | 0 | 261 |
| View specs | 116 | 87 | 0 | 0 | 0 | 0 |
| Acceptance specs | 2432 | 2274 | 0 | 0 | 0 | 0 |
| Javascript specs | 630 | 433 | 0 | 173 | 0 | 0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total | 31430 | 23675 | 428 | 1845 | 4 | 10 |
+----------------------+-------+-------+---------+---------+-----+-------+
Code LOC: 12917 Test LOC: 10758 Code to Test Ratio: 1:0.8
而且,即便是小项目,也是个好习惯。我两周前刚开始自己写的一个小产品的数据——
+----------------------+-------+-------+---------+---------+-----+-------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Decorators | 6 | 6 | 2 | 1 | 0 | 4 |
| Services | 155 | 95 | 3 | 12 | 4 | 5 |
| Controllers | 310 | 201 | 5 | 34 | 6 | 3 |
| Helpers | 5 | 5 | 0 | 1 | 0 | 3 |
| Models | 202 | 77 | 6 | 6 | 1 | 10 |
| Mailers | 0 | 0 | 0 | 0 | 0 | 0 |
| Javascripts | 68 | 45 | 0 | 8 | 0 | 3 |
| Libraries | 0 | 0 | 0 | 0 | 0 | 0 |
| Controller specs | 323 | 238 | 1 | 2 | 2 | 117 |
| Decorator specs | 19 | 14 | 0 | 0 | 0 | 0 |
| Helper specs | 9 | 7 | 0 | 0 | 0 | 0 |
| Model specs | 217 | 85 | 0 | 0 | 0 | 0 |
| Service specs | 82 | 63 | 0 | 0 | 0 | 0 |
| Acceptance specs | 117 | 108 | 0 | 0 | 0 | 0 |
| Javascript specs | 31 | 0 | 0 | 0 | 0 | 0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total | 1544 | 944 | 17 | 64 | 3 | 12 |
+----------------------+-------+-------+---------+---------+-----+-------+
Code LOC: 429 Test LOC: 515 Code to Test Ratio: 1:1.2
用 inherited resources 的同学们注意了,4.2 版本的 responder 更改导致 inherited resources 无法使用。
#28 楼 @zzz6519003 貌似没啥特别的优势~ 呵呵~
保持干净整洁的 .blahrc
文件是个良好习惯哟~
对,很多东西需要重装。完整的备份不推荐用 TimeMachine。
对 Lotus 的设计理念有迟疑或不解的同学可以看下我在这个贴子里的回复:https://ruby-china.org/topics/20130#reply25
#20 楼 @rainchen #21 楼 @ashchan #22 楼 @hooopo
Lotus 的设计理念是 decouple 至上 —— 这是从 Luca(作者)他们团队项目的高复杂度中衍生出来的。这点我非常能够体会到,因为我们团队现在开发的应用也是高复杂度,大部分逻辑都是在 Rails 以外实现的。
@rainchen 吐槽的绝对合理,但是其实只是因为框架还未成熟。从 decouple 化的架构增添 DSL 或 abstraction layer,要比 decouple 像 rails 这样庞大的框架要容易的多了。
Lotus 目前为止毕竟是 Luca 一个人的产物。很多 API 还不人性化是肯定的。作为开源的一个项目,还是需要社区的支持的。这几天 Luca 开始添加 issues 了,比如 Lotus::Model 的:https://github.com/lotus/model/issues 我会尽量帮助开发 Lotus::Model,希望我们社区有兴趣的人也能尽量添一笔力量。
对于这点——
非常同意@luikore的看法:“正常脑子都会想到 instance 和 class 而不是 entity 和 repository, 语言提供的设施不用,自己造一堆是为何...”。
我完全不赞同。instance / class
与 entity / repository
完全是两码事,在同一个句子里出现有些古怪。如果你们看过 ROM 或是我的 Datamappify 的话,就会了解为什么要 entity / repository
了。对于简单的应用(比如一个 blog)而言,ActiveRecord 很方便,但对于搞复杂度的大型应用而言,data mapper 这个 pattern 的优点远大于缺点。
Data mapper pattern 最重要的一个优势,是在 Datamappify 的 README 里提到的:
The coupling between domain logic and data persistence.
DSL 可以不断的优化,但是基本的设计理念是非常难修改的。Rails 有几千个人提交代码,但 ActiveRecord 始终是一个难题。
DSL 的优化当然也要看是否与设计理念产生冲突,比如说 @rainchen 提议的这个委托 DSL:
author = Author.new(name: 'Luca')
author.repository.save
author.repository.delete
这个就与设计理念有冲突。因为作为 entity 而言,是不允许有任何的 repository 的 knowledge 的。这个不仅仅是设计 DSL 的问题,而是代码的 semantic 和对象的 responsibility 的问题。
当越来越多的 ruby/rails 程序员跑去其他社区(go 啊,elixir 啊,closure 啊之类的),ruby 社区需要像 Lotus 这样把设计放第一位的框架。
我为 Rails 做过贡献,但是每次打开 Rails 的源代码,都是这个表情——
而我初次看 Lotus 的代码时,表情是这样的——
大家升级 4.1.2 或 4.0.6 后如果 HABTM 的 collection 计算结果有问题的话请联系我:
4.1.2:
Fixed has_and_belongs_to_many's CollectionAssociation size calculation.
has_and_belongs_to_many should fall back to using the normal CollectionAssociation's size calculation if the collection is not cached or loaded.
Fixes #14913, #14914.
Fred Wu
https://github.com/rails/rails/blob/4-1-stable/activerecord/CHANGELOG.md
4.0.6:
Fixed has_and_belongs_to_many's CollectionAssociation size calculation.
has_and_belongs_to_many should not include new records as part of #count_records as new records are already counted.
Fixes #14914.
Fred Wu
https://github.com/rails/rails/blob/4-0-stable/activerecord/CHANGELOG.md
刚才在 Skype 上和作者 Luca 聊了一个多小时关于 Lotus::Model 的开发计划,受益不浅。相比较 Datamappify 的 Entity + Validation 和 Repository + Mapper 的设计,Luca 的 Lotus::Model 把所有东西都细分化了,架构更明显。接下去我会尽量抽点时间来为 Lotus::Model 做点微薄的贡献。
这个项目我推荐大家用来学习 —— 代码非常整洁有条理。是继 Ruby Object Mapper 后首个让我眼前一亮的项目。:D
移民了后别忘了来请我吃饭~ :trollface:
如果只需要数据绑定的话可以看一下 Ractive.js。
我来贴一下自己的车牌,嘿嘿嘿... :trollface:
我们用 Slack。:) 不过 HipChat 新加入了 screensharing 功能应该蛮有用的。
看到 unless ... else ...
直接打脸。:trollface:
Code in the application helper is included in all the views in your application. Code in other helpers is included in the corresponding view.
这段是错误的。