1. 梳理产品的所有需求点,先按功能分,再根据优先级标号列表

    2. 把所有涉及的数据实体列出来,尽可能细化,后期发现粒度太细再合并就好

    3. 把实体的关系画一下,理清楚

    4. 考虑一下实际的用户场景 (user story),大概判断一下哪些场景是高频,数据的特征是怎样 (特征是指,W 多? R 多? 改动频繁? 一条数据大小怎样?)

    5.大致搞清楚之后,先拿 MySQL/PostgreSQL 当基准,再看看是不是要根据特征添加/ 更换数据存储

    6.一套下来大概也知道该怎样设计了

  • DHH 说的没错,但是只限于他们的场景。想想这么两个问题, 1、Rails 的掌控能力(工程能力)2、业务跑通了,能赚钱(业务能力)

    这两点其实放在任何一个团队公司都是一样的。如果你的团队对自己用的工具有绝对的掌控能力,并且你们的业务也已经被证明是能生存的,那其他事情其实都不重要。

  • yield + block 实际上就是 closure,搜一下 python 的 closure 你就知道了

  • Nice work

  • 找了一下,还是有一些应该能用的。但是不太懂字体的情况,没法提供太多的建议,见谅。

  • title 为中文的时候字体有点违和,有没相应风格的中文字体?

  • 是否采用多态关联表还是要看具体业务。标签系统用来做什么,产生的数据输出的目的是什么,是否有后续的处理需求。 是用多态或者单表其实不重要。

    打标签和全文搜索没有冲突,或者说两者的目标其实不是一回事。

  • 我也在考虑这个问题,阿里的鉴黄用起来还是很舒服的,但是这个内容检测还没仔细研究过,暂时不敢轻易上

  • 这…牛逼… 我下了那个和谐宝典,研究了下大致能用。 但是里面的词表误伤范围太大。可怜我现在在人工复审那份词表,一个个人工过滤,不确定的就在微博上搜…

  • 现在很多云服务都是每月自动扣费的,所以这个事情应该是现成可做的,只是要绕一下弯。

  • 区块链可能某种程度上有新意,但是创新和违规违法还是要区分开。不是说把白粉换个名字叫白面就合法了。

  • 第二个,直接在网址上提供捐赠的链接,然后绑定对应的账号,这个不是现成的方案么?每月的捐赠能不能满足续费的需求倒是不好说。

    第一个,建议你先去研究一下付款会员服务的协议,一般应该都是禁止这种明面的分享行为的,你拿这个来当二房东,服务提供方随时封你账号不退费你没话可说。

  • 所以到底实质创新是什么?

  • 所以这个 token 的创新在哪?

  • Linux、Ruby 不冷没天理! at 2018年02月01日

    为什么在一个专业技术论坛里面还会有这种莫名其妙的帖子?为什么这年头还有人拿 windows linux 来说事?MacOS 情何以堪?

    干嘛不把这帖子锁了浪费大家的表情…

  • 谨防比特币和区块链骗局 at 2018年01月25日

    最近几年的各种风口非常有意思。 有个做产品经理的朋友曾经提过,他想做一个健康监测的 AI 项目。我好奇,问这种怎么 AI 法,他说,监测数据收集大数据,然后就能 AI 了。我一愣,他补一句,这半年再不做 AI,风口就过去了。

  • 谨防比特币和区块链骗局 at 2018年01月25日

    就跟前段时间什么破项目都挂个 AI 就能喊高价一样。 只是区块链因为比特币的加持有赌博成分对一般个人更有风险。

    再过半年自然就知道了。P2P 的风潮过后现在不是才开始清算? 问题会陆陆续续暴露出来,该跳楼的跳楼,该进去的进去。

    做技术的继续保持低调和淡定去判断技术是不是合适自己的项目即可。

    16 年 AR/VR 不是很火么,现在在哪了? 17 年 AI 也很火,现在呢? 18 年区块链炒一炒,之后呢?

    对工程师/创业者来说没关系,重点不在技术,在于项目,技术能不能用之于项目,引爆项目。 AR/VR 二十年前就有了,AI, 现阶段应该说是 ML,也是二十年前就有了,区块链呢?难道忘了 BT? 投资/风投圈需要风口,一方面需要吸引别人来投,另一方面需要吸引别人来炒。

    淡定看猪飞,低调做项目,如此而已。

  • Rails 部署负载均衡代理 at 2018年01月09日

    不太明白你说的意思。但是你的场景应该是前面一台 Nginx 做 LB, 后面两台 rails。 一般的处理印象中是 nginx 配置好 LB 规则,然后绑定两台 rails 的内网 ip:port 就完了,rails 端起好 puma。这个结构并不是一个复杂的东西。

  • 跟什么学校毕业和读什么专业无关,跟人会不会学习会不会表达有关

  • 功能开关或者插件 (Engine) 方式应该是唯一办法。维护多分支不见得能让工作量和出错几率减少。 你说不希望代码里出现太多这样的开关,要不是代码洁癖,要不是代码的控制不到位。 还有种可能是你们的代码会提交给客户方,怕他们乱搞或者其他潜在问题。那就做成 Engine,他们需要什么功能就给他们那些功能。概念上和功能开关差不了多少。

  • 不建议在 js 里面直接使用 erb 得到数据,这样做太多不可预见的坑,把逻辑整理得简单点会更 reliable

  • 出个 20k 我相信你的问题会在一天内有人响应和完成

  • 一个 gem 的好坏和是否适合 newbie 没有必然关系。

    devise 是好东西,但是也太复杂。在选择工具的时候需要有明确的需求判断。如果还无法判断自己的需求,老老实实跟着 tutorial 从最简单的做起是最好的选择。