不能。

https://launchschool.com/

是的，是线上的培训

后端花的时间少些确实很粗糙，确实会有性能问题。现在希望能有些大站入驻能够更好地观察实际的数据。这类大量写入查询分析的项目还是挺有意思的，欢迎有兴趣的同学参与开发

正在帮助他在硅谷找工作，希望能帮他入职一家好公司。

代码有很多围绕一个层级型数据结构的 set/get 的操作，以及相应的 if .. else ..

建议围绕核心数据面向对象为 Node, Interface 等类（如果有逻辑）或者 struct (如果无逻辑）。

http://wiki.c2.com/?PrimitiveObsession

#10 楼 @luming 全部课程人民币估计一万多 不过也就是大多职位不到一个月的工资

如果想系统性的学习和成长，可以考虑到我们这里来上课： https://launchschool.com/

我们在 ruby/rails 方面有几年的积累，课程体系很完善，应该是远超一般企业对新手 Ruby 程序员的要求。

缺点是 1. 比较贵 2. 时间长 3. 需要很强的自觉性和恒心 4. 全英文

#15 楼 @kgen 谢谢！

#16 楼 @fsword

在游戏流程控制上，感觉是你是在用类似即时战略游戏的思想来实现回合制的游戏 :) 事件驱动和绑定玩的蛮高端，对这个题目是牛刀了，因为本身游戏的流程可以都放在 game loop 里面的，而且总是 玩家 -> 电脑 -> 重新画屏。你的实现方法如果是很多玩家同时乱打倒是很合适的。

在跟踪状态和建模上面，用每个 shot 引起从 TeamController 到 Team 到 Matrix 到 Ship 的状态改变，以及 MatrixDelegator 对 Matrix 本身的加强，感觉对象间太多依赖，交互太多；从另一个角度看，这些对象除了 Ship 外都比较浅，执行形式以 delegation / pass through 为主（尤其是 shot_at 的 delegations ), 可以考虑把一些对象变化成类似 transformation 的函数。在代码从面上，你大多数的方法是以 command / delegation 为主，如果多考虑用 数据进 ／数据出的函数，会逼迫你简化对状态的代表方式，从而减少总体复杂度。

@fredwu 请推荐些适合新手读的 Ruby/JavaScript 的开源项目，工具／库或者 应用 都好，谢谢！

墨尔本／悉尼／ Brisbane 本地对初级 web developer 的需求怎么样？

#11 楼 @fsword 别太在意时间 :) 欢迎分享心得！

一些解题帮助：

这个练习题有满多的复杂性，主要呈现在两个方面：1. 如何记载和跟踪游戏状态，以及带来的怎么样的面向对象的数据封装比较合适？2. 如何把一个大的题目化整为零，来计划一步步的实现过程？其他在具体的算法和编程方面并不是很难。

在第一个方面，可以首先在全局上检查可能需要追踪的游戏状态：

－ 两个玩家（电脑／人） －两个棋盘及其方格 － 游戏状态：现在该哪个玩家打；是否有人胜出 － 所有方格的状态（被打击但无船；被打击打到船；未被打击） － 所有舰船的方位和朝向 － 舰船的状态（未被击沉／被击沉） －朝每个棋盘发射过的所有炮弹

在面向对象编程的框世里，一般来讲是把名词抽出来作为对象的，比如说这里面的 玩家，舰船，炮弹，棋盘，方格，游戏。但如果从这个角度入手，往往在一开始的时候就面对着如何设计对象层级及对象间交互的方式，是比较困难的。有些同学会不太多考虑的选择几个概念来封装成类，代码写起来再说，但其实不理想的封装会带来后面程序复杂度的大幅度提高。

可以考虑这样一个角度：如果检查所有的状态，会发现这些游戏状态并不是互相独立的 － 而有些状态是可以从其他的状态计算出来的 － 比如说所有方格的状态可以由舰船位置和所有炮弹的位置计算出来。在选择类／对象的时候，尽量选择基本的，相互独立的状态，把它们封装，由他们再计算出其他的状态。

还有一个角度，是优先考虑再问题描述中高频出现的概念。在这个问题描述中，“船”的概念非常频繁的出现，这说明在这个题目里，有很多的算法（步骤）和逻辑对”船“这个概念是有依赖的。所以把”船“抽象出来作为一个基本砌块是有优势的。而如果不固化这个概念，势必在代码中到处计算和反推这个概念，增加不必要的复杂度。

在选择出基本的几个状态及类封装后，可以回头把需求中的所有逻辑和其他状态 向选择的基本状态沉积。这样程序的大体框架就有了。

下次讲 化整为零 解决问题的方法。

#7 楼 @msg7086 开炮！

#6 楼 @oth 谢谢！

#5 楼 @w7938940 可以啊，欢迎借题发挥

#3 楼 @duobei 视频就在上面的链接里面。讨论直接在这里就可以了 － 我会在这里给予反馈和点评。

如果想在 Launch School 里面参加讨论，可以到这个链接（需要注册）

https://launchschool.com/posts/974de05b

恩，还没明白我这种场景应该是用什么样的方案？

比如 客户端 可以方便的 cache 服务器端返回的带有 UUID 的 json - 直接按 uuid 扔到比如 Redis 里面就行了

https://github.com/brandonhilkert/sucker_punch

@hooopo

我的态度就是，当一件事事情是模棱两可的，可以很严重也可以不是那么严重的时候（一边是玩笑开大了，另一边是性别歧视），不要随便把问题扩大化。界定标准就是一个问题，你觉得不可以接受，我觉得可以接受，为什么要按你的观点来？对结论性的东西要慎重。

这次本来就不是辩论，我也没有兴趣说服你要按我的观点来。在你看来的问题扩大化，在我看来已是难以接受的偏见和歧视 － 但这也很正常。但正是对于这样的看法不同，才更要各自发声不是么；对于结论性明晰的事情（比如明显的歧视和仇恨）还有什么说的必要？

这种确实存在，也不仅限于女性被当成花瓶，被调戏、不给同等工作机会。但这种事情不是网友能管了的，得靠制度和法制的完善。如果靠网友的道德审判这又倒退了。

法律和制度是最下的底线。法律上已经很明晰的事情都不需要讨论，直接上法庭就好了。制度和法律不会自己完善，而是反映社会的价值取向。而不论是远一点的民权运动还是近期的同性恋权益，舆论和“民心”不仅是走在法律前面，还是推动法律和制度改变的原因。说到倒退是反了吧。

话说回来一开始的时候根本没想这么多，只是觉得那文章很过分。后来论坛上的一些看法倒让我觉得应该多说几句

一个类似的事件： http://readwrite.com/2012/03/20/how-casual-sexism-put-sqoot-in

Sqoot 公司在宣传 Hackthon 的时候把 Women 列为活动的好处之一，在各方压力下道歉。

第一次道歉用语：

While we thought this was a fun, harmless comment poking fun at the fact that hack-a-thons are typically male-dominated, others were offended. That was not our intention and thus we changed it.

这和 Coding 的道歉原因为”不合适的推文造成社区成员的不快“，而今后的做法是“（不贴类似文章，而）讨论优质技术干货”是如出一辙的。似乎错误的原因是 文章贴错地方而已。对文章本身如何不合适没有任何承认和担当，而且几天后还留在线上。

Sqoot 公司第二次，被接受的道歉（原文）

We Can Do Better: An Apology from Sqoot

Recently, we decided to host a hack-a-thon in Boston. Our goal: to bring developers together with the community and new technologies to build amazing things. Like any good party, we wanted great music, great people, and great food. We wanted to do better than pizza and soft drinks, and truly wanted everyone involved to benefit in a big way. We didn’t want developers to leave in the same cliques they came with because of a lack of cross-pollination nor did we want sponsors to spend thousands of dollars yet still miss connecting with ideal users. We really wanted to do better.

Unfortunately, we did worse. When we put together the original event page, we used language that we now realize was reckless and hurt efforts to diversify gender in tech. We immediately and deservedly received an enormous backlash. While we aimed to call attention to the male-dominated tech world through humor and intended to be inclusive, the gravity of our wording was just the opposite. Our words completely undermined our intentions and went further to harm the world we’re trying to have a positive impact on.

We apologize unequivocally to our sponsors, customers, friends and family, and community. We’d like to thank everyone for being so outspoken. As a young startup, we learned a lot today and are better people and a better company for it.

As we decide whether to continue with the event, or reschedule for another time, we will focus efforts on making sure that our event marketing is inclusive to all. We will do better.

If you have any questions, or want to chat, don’t hesitate to reach out.

Sincerely,

Mo, Avand, & Sqoot
[email protected]

请 Coding.net 决定是不是应该公布更有诚意的道歉

如果我们把区分当成歧视，那么歧视无处不在，我们每个人每天都在歧视。我们要反对的歧视是制度性歧视。

制度性／大范围的歧视现在已经很少见了，Sexism 的体现更多是性别主义的言论，来自 @shiningray 所说的偏见和刻板印象。偏见和刻板印象确实是无处不在，但用这个原因而只反对 制度性歧视，而不反对性别主义的言论是不够的。举个例子，北美的华人圈很多人是有种族偏见的，在中国人的 party 上很多人总是说老墨如何如何，老黑如何如何，而且大多带有贬低性质，在种族这个层面上一概而论。如果你反对 Racism, 这些时候就要发声。如果你认为诸如“在加州的老墨 99% 都是偷渡过境打黑工不思进取，只有 1% 会正经工作“是种族主义言论（即使只是玩笑话，因为明显不是事实），那么“99% 的妹子是想搭讪你，只有剩下 1% 才真的只想学写代码“就是性别主义的言论。

我生活过的地方没有看到过制度性的性别主义，但性别主义的言论无所不在，而亚洲国家尤其严重。我觉得这个链接上的 5 点如何分辨性别主义言论不错，摘抄一下：

Figure out what kinds of remarks are sexist. To do so, you might consider the following questions:

• Is the remark designed to make women (but not men) uncomfortable?
• Does the remark limit women’s (but not men’s) freedom of expression or behavior?
• Is the remark likely to make those who hear it take women less seriously because of their gender?
• Could the remark also be applied to men and make sense?
• Does the remark make generalizations about individuals on the basis of gender?

#22 楼 @hooopo

回到“Rails Girl”，Girl 本身就是活动的一个噱头，假设活动改为“Rails Boy”会达到现在的关注程度么？可能也会有热心的教练，但不可否认，有了 Girl 让教练更加热心。反过来 Girl 也是一样，有想学 Rails，顺便和 Coach 交流一下的；有想和 Coach 交流，顺便学一下 Rails 的。其实社交问题是实实在在存在的问题，却被刻意回避和无视，这让我想起了《房间里的大象》。

我们公司和我本人从两年前开始做教练和赞助 Rails Girls 和 Rails Girls Summer of Code, 可以说最起码在美国这边这个活动时非常认真的纯技术互助活动，大多数的教练已经是成家，根本谈不上什么“社交问题”。如果说是“噱头”，这个“噱头”是鼓励想学习编程的女孩来参与，让她们觉得这是一个受欢迎的学习环境，让她们觉得”别听别人怎么讲，只要你愿意，我们可以帮助你成为一个程序员“。

你可以自己 Google 一下 "my experience at rails girls", 会有很多的从学员和教练角度的分享。如果你认为所有的分享都在“刻意的回避和无视”社交问题，那我没什么可说的。

让一个自己承认没有参加过任何 Rails Girls 活动也没有兴趣参加的人对活动有这样的臆测，是可以反映很多社区人对这个活动的印象的。除去来自个人的偏见，组织者和推广者对活动的宣传 和 对不符合活动价值言论的态度和处理方式 是会对社区有非常大的影响的。

支持 @rei，有些事情就得认真。

练重构到看到烂代码就兴奋的变态境界就行了

元编程是一种抽象的手段，但大多 Rails 项目是针对业务的，而业务本身和业务内部很难有清晰，稳定的抽象界限。稳定的抽象往往是业务面对系统；业务面对网络；业务面对第三方软件库等；而在这些方面的元编程一般已经有人封装好成 gem 了

Ruby 社区的问题就是太多人成长成 Rails 程序员了

Ruby 服务器的接口协议 + 网络开发的一些常用工具库 + 服务器端网络中间件框架