好看的前端妹纸、好看的产品妹纸、好看的测试妹纸、好看的设计师妹纸 : )

光说好看有什么用，照片都莫得 。

hexapdf 考虑一下

https://github.com/gettalong/hexapdf

考虑下？

来不及解释赶紧上（瑞卡租）车先，能从上图找到我的我给你内推。邮箱:hemz#reocar.com

大概是因为 Ruby 被黑的多了，RubyChina 就成了这个颜色吧，说实话感觉有点突兀，不过萝卜青菜各有所爱，众口难调，理解万岁！

今天实在忍不住说一句，千万别像下面这样用：

enum status: %w(active disabled 110 120 119)

@ruby_sky 你值得拥有

感谢安道！

你酒店也订国际这边来吧，我们一起组队过去。

收到多会的短信了，老铁，不厚道啊。

你这么晚才下单？！！！

你这有很严重的广告嫌疑啊，说的我都想试试了。传销！

星级大厨做饭

谢谢建议，已修改。主要是完事之后 push gem 才发现 jd_pay 重名了！感觉修改 repo name 之后跟项目代码的 JdPay 风格有点出入。

没有联系方式的招聘贴都可以理解为打广告

1. super 代表它使用了父类ActiveRecord::Base的#initialize方法；
   
2. ActiveRecord::Base中描述了#initialize Methods included from Core;
   
3. 具体定义在这里

你是背了 94 万的债，还有 180 万的房产，关键债务还是 30 年偿还期是不是？

你到底是怎么胖了 30 多斤的？

不是 5 块吗？人不熟还涨价啊

彩程 支持。

首先，我们来选个切入方向, 这里我就从用户的角度入手。
step by step:

1. 用户最能直观感感受到的其实就一部分，试卷TestPaper
   这里就要分我们要不要对用户的答卷做记录，如果要记录的话就需要用户答卷记录表AnswerPaper； 这里我假定需要记录，所以目前就有 2 个主要 modelTestPaper、AnswerPaper。

2. TestPaper 部分
   试卷无非就是问题Question和答案Answer组成的，这里面会有很多跟具体场景关联的细节的问题，编码的时候根据需求再扯。

3. AnswerPaper
   我们很容易从试卷的结构分析出答卷的详情的AnswerPaperDetail内容。

4. 下面进入拟表环节
   我这里按我的理解简单罗列一下就行了，具体看你自己根据实际需求：
   

   # 这里看你需不需要用相同试题记录生成不同的试卷，如果不需要的话，直接把`test_paper_id`加到`Question`.这里就不需要question_ids数组了
   TestPaper(id: uuid, name: string, code: string, question_ids: text);
   AnswerPaper(id: uuid, test_paper_id: uuid, user_id: uuid);
   # q_type主要用于判断问题类型(单选题、多选题、填空题)，category_id判断问题所属的行业或者年级，算了越拓展这表越大，自己看着办。
   Question(id: uuid, content: string, q_type: string, order_num: integer, category_id: uuid)
   Answer(id: uuid, content: string, order_num: integer, is_right: boolean)
   # answer可以存放不同类型问题的答案，如果你只有选择题可以存放answer_ids
   AnswerPaperDetail(id: uuid, answer_paper_id: uuid, question_id: uuid, answer: text)
   

5. 表之间的关联应该很清楚了吧，我还有事就不写了 (表之间关联的分析应该在拟表之前)
   

以上就是我的分析过程。

感觉感谢说多了好无力，不过还是应该说感谢，此处应有打赏。

这个时候私聊的应用场景就诞生了

平时看帖不发帖，感觉还是不错的。只是没有了订阅通知和导航。

你反正是万金油，无所谓！

讲道理二维码应该能覆盖条形码的使用场景吧，现在很多浏览器都支持扫描二维码跟条形码啊。

我的天

你这头像是本人吗？

来呀 互相伤害啊