cn_boris (Boris Ding)

[远程或宁波] 30-60K Brickdoc 招聘软件开发工程师

cn_boris — Sun, 11 Apr 2021 12:44:19 +0800

我们是谁

人类一直寻找能够用视觉符号方式表达思想感情的方法，寻找能够利用图形储存自己的记忆和知识的方法，寻找能够把信息的传达程序化和简单化的方法。文字的产生、印刷的发展、相机的发明、互联网的普及，都代表了这种努力。思维与技术的交替成长，直到今天依然代表了这种探索的继续。 ──《世界现代设计史》王受之

Brickdoc 是一个以 Open-core 模式商业化开源的新一代协同文档系统（目前正在开发中，计划于今年年中正式以 Apache-2.0 协议开源）。通过整合在线文档，RPA 和云事件总线功能，其模糊了文档与软件之间的边界，从而使得用户无需编写任何代码即可拥有将一部分工作自动化的能力。以 Word 和 Excel 为代表的通用办公软件已经成为数字世界不可或缺的重要支柱，但事实上诞生于 40 多年前（以 VisiCalc 的发布日期记）的它们是建立在对于纸质文件的拟物化隐喻之上的。在那个时代，以数字化方式存储信息仅仅是为了加速处理信息所产生的「临时文件」，信息最初的来源和最终的去向依然是被构建于纸张之上的。

在 21 世纪 20 年代的当下，信息时代的「童年」已经终结。信息爆炸意味着以数字化方式存储的信息已经成为了世界运作所不可或缺的一部分──而不仅仅是过程产物。正如当下的 UI 风格已经完成了从拟物化到扁平化的转变一样，我们迫切需要一款面向下一个十年的通用办公软件来增强人类获取，处理以及分发信息的能力。并最终实现 Douglas C. Engelbart 所畅想的藉由人机协同来提高人类智能（augmenting human intellect）美好愿景。

我们怎么做事

类似 Basecamp（原 37signals）的精英化小团队
从开源中来，到开源中去──我们是 CNCF 和 W3C 的成员单位
通过商业化实现可持续的开源──稳健营收而非用爱发电

我们的技术栈

Ruby on Rails 单体应用
一小部分使用 Rust 和 C 编写 Ruby Gem
基于 React 开发的 PWA（重度使用 RxJS）
GraphQL API
基于 Single SPA 和 serverless 的插件化扩展体系
Kubernetes & Helm
基于 WebAssembly 实现的 mruby 前端解释器

我们在找怎样的人

软件开发工程师（前端或全栈）

你将负责下述的一项或多项：

参与 WYSIWYG editor 和 blockly-like visual programming editor 的开发和持续优化；
参与 React PWA 和 GraphQL API 的业务开发；
参与开源社区的治理工作──处理各类 Issue 和 PR, 解答社区疑问；
代表公司参与 W3C 关于未来 Web 标准的技术研讨；

我们期望你：

掌握或愿意学习右述技术/算法：React(or Angular), TypeScript, Apollo GraphQL, RxJS, Module Federation, ProseMirror, Service Worker, Custom elements, WebAssembly, Conflict-free Replicated Data Types, Finite-state machine
拥有基本的服务器端编程经验（NodeJS 或其他语言均可），基本掌握至少一种关系型或非关系型数据库的使用;
拥有基本的算法和数据结构常识；
具备强烈的技术进取心和好奇心，热衷于关注相关技术前沿发展趋势，有良好的沟通与合作精神，拥有优秀的问题分析及解决能力；
能够无障碍读写英文技术文档（不要求听说）;
有较强的自驱力和自控力，能够适应远程工作；
认同「Develop a team as a product」。参与前端工程化建设以及各类内部工程效率工具的开发，致力于持续不断地通过自动化手段和方法论提升团队及自身的工作效率；
具有高度的 Ownership 参与产品设计和需求梳理，愿意从自身的专业角度出发与团队的其他成员一起探索持续提升用户体验的可能。

软件开发工程师（后端或全栈）

你将负责下述的一项或多项：

参与 WebAssembly 的相关开发工作；
参与 GraphQL API, serverless functions 和各类后端业务逻辑的开发，交付高质量的代码并持续进行性能优化；
践行 DevOps 思想，负责相关服务在 Kubernetes 集群中的部署和维护，确保生产环境的 SLA；
参与开源社区的治理工作──处理各类 Issue 和 PR, 解答社区疑问；
代表公司参与到 CNCF 的社区工作，特别是 cloudevents spec 相关的工作；

我们期望你：

拥有良好的算法和数据结构功底，熟悉常用的设计模式；
熟悉 Ruby 语言或有兴趣以 Ruby 语言作为主要工作语言;
掌握或愿意学习右述技术：Ruby on Rails, PostgreSQL, Redis, RabbitMQ(or Kafka/ NATS / AWS SQS), Kubernetes, Knative；
基本掌握右述语言中的一种或多种：Java/Kotlin, Go, C/C++, C#, Rust, Haskell/Lisp/Clojure, TypeScript；
基本掌握 HTML, CSS 和 ECMAScript;
了解 Web 应用常见漏洞，了解静态漏洞扫描工具，安全意识高
有编写自动化测试习惯，熟悉 CI/CD 流程，编码习惯良好；
具备强烈的技术进取心和好奇心，热衷于关注相关技术前沿发展趋势，有良好的沟通与合作精神，拥有优秀的问题分析及解决能力；
能够无障碍读写英文技术文档（不要求听说）;
有较强的自驱力和自控力，能够适应远程工作；
认同「Develop a team as a product」。参与各类内部工程效率工具的开发，致力于持续不断地通过自动化手段和方法论提升团队及自身的工作效率；
具有高度的 Ownership 参与产品设计和需求梳理，愿意从自身的专业角度出发与团队的其他成员一起探索持续提升用户体验的可能。

如何联系我们

请投递PDF 格式的简历至 careers@brickdoc.com，简历中随附 Github ID 有加分。

Shopify 的 GraphQL API 设计指南

cn_boris — Sun, 13 Dec 2020 22:35:44 +0800

最近在研究 GraphQL 相关的最佳实现，然后看到了 Shopify 的 GraphQL API 设计指南感觉收益颇丰。顺手翻译成了中文版分享给大家。

教程：GraphQL API 的准则

本教程最初由 Shopify 基于内部需求而撰写，但考虑到它对于任何准备编写 GraphQL API 的人有帮助因此我们创建了这一对外的公开版本。

它参考了最近 3 年来 Shopify 在生产环境中开发和迭代 GraphQL API 所获得的经验和教训，并将持续更新。

我们相信这些设计准则在绝大多数情况下都是适用的。但它们可能未必完全适用于你的需求，即使在 Shopify 内部这些规则也未必 100% 的适用于所有场景。因此请不要盲目的照搬和实施下述的所有设计准则。

简介

欢迎！本文档将指导您如何设计新的 GraphQL API。API 设计是一项极具挑战性的任务，它需要你对于业务场景拥有深刻地理解并且不断的进行迭代和实验。

步骤 0: 假定背景

为了本教程之目的，你需要想象自己正为一家电商公司工作。目前这一电商平台已经拥有 1 个可以查询商品信息的 GraphQL API。在最近的产品迭代中，你的团队刚刚完成了「商品合集」功能的后端开发，你被指派负责开发该功能的 GraphQL 接口。

商品合集本质上是一个类似收藏夹的功能，允许商家对于商品进行分组——从而实现例如在某个专题促销页中仅展示某个特定合集中的商品或「某个特定合集中的商品打 85 折」之类的程序化任务。

你的同事已经完成了这一需求的业务逻辑设计，具体如下：

所有的合集都包含诸如：标题、详情描述（可能包括 HTML 片段）、缩略图等基础字段。
合集有 2 种类型，分别是需要人工添加商品的手动合集（ManualCollections）和能够按照规则生成的自动合集（AutomaticCollections）——例如可以创建 1 个自动合集，该合集会将店铺内的存在 XL 码库存的所有男装都加入进去。
商品和合集之间是多对多（many-to-many）关系，在数据库层面存在一个叫做 CollectionMembership的中间关联表。
就像商品可以设置上下架一样，合集也有一个字段可以设置其是否生效。

我们将基于上述的假定需求来进行 API 设计。

步骤 1: 全局概览

不考虑架构的话，这一功能最为简单粗暴的 GraphQL Schema 设计可能是这样：

interface Collection {
  id: ID!
  memberships: [CollectionMembership!]!
  title: String!
  imageId: ID
  bodyHtml: String
}

type AutomaticCollection implements Collection {
  id: ID!
  rules: [AutomaticCollectionRule!]!
  rulesApplyDisjunctively: Boolean!
  memberships: [CollectionMembership!]!
  title: String!
  imageId: ID
  bodyHtml: String
}

type ManualCollection implements Collection {
  id: ID!
  memberships: [CollectionMembership!]!
  title: String!
  imageId: ID
  bodyHtml: String
}

type AutomaticCollectionRule {
  column: String!
  relation: String!
  condition: String!
}

type CollectionMembership {
  collectionId: ID!
  productId: ID!
}

即便只有 4 个对象和 1 个接口，但这样设计依然看起来有点过于复杂。而且，它似乎并没有完全地满足业务需求，例如我们需要使用这样的 API 来完成手机 App 上的合集功能似乎就不太够用了。

基于我们的经验，用一个由多个对象、数十个字段揉杂在一起所构成的 Graphql API 来实现某一业务需求往往是混乱和错误的开端。你应该从更高的抽象层级进行思考，着眼于类型（GraphQL Type）及各个类型之间的关系，而非数据库层面的具体字段或对 CRUD 接口进行简单罗列。从实体关系模型（Entity-relationship model）开始思考会是一个好的选择。

在开始正式重构前，我们先把当前设计中所有不需要关注的细节隐藏起来以利于我们接下来的思考：

interface Collection {
  Image
  [CollectionMembership]
}

type AutomaticCollection implements Collection {
  [AutomaticCollectionRule]
  Image
  [CollectionMembership]
}

type ManualCollection implements Collection {
  Image
  [CollectionMembership]
}

type AutomaticCollectionRule { }

type CollectionMembership {
  Collection
  Product
}

规则一：永远先从更高的抽象层级进行设计，先考虑类型与类型之间的关系，再去考虑具体的字段。

步骤 2: 少既是多

接下来，让我们着力于解决简单粗暴版本中的核心问题。

如前所述，在数据库中本需求由通过自动合集表、手动合集表以及用于实现商品与合集间多对多关系的中间表这 3 张表来实现。我们现有的 GraphQL API 设计完全照搬了这一关系模型，但这实际上是错误的。

这一错误的核心问题在于，API 设计和数据库设计有着不同的抽象层级和使用目的。在 API 设计中不加思考的照搬数据库表结构，往往会把我们引入歧途。

避免暴露 `CollectionMembership` 表

你可能已经注意到 CollectionMembership 表实质上是一种技术细节，对于业务场景而言它实质上应该是一种黑盒实现。

也就是说我们不应该在 API 设计中将它暴露出来，因为我们的 API 是对于业务模型而非技术细节的抽象。因此我们可以进一步将 Schema 重构成下述版本：

interface Collection {
  Image
  [Product]
}

type AutomaticCollection implements Collection {
  [AutomaticCollectionRule]
  Image
  [Product]
}

type ManualCollection implements Collection {
  Image
  [Product]
}

type AutomaticCollectionRule { }

This is much better.

规则二：永远不要在 API 中暴露不必要的实现细节。

重新思考合集

现有的 API Schema 设计依然着一个因为我们没有深入理解业务知识而产生的缺陷。我们把自动合集和手动合集设计成两种不同的 GraphQL 类型，他们都继承于同一个公共的集合接口。从技术上说，这一的设计似乎是符合逻辑的——他们有许多相同的字段，但本质上它们的功能由存在着明显差异。

但从业务场景角度思考，这种差异实现是也只是一种实现细节上的差异。它们在业务场景中所实现的功能是完全一致的——将若干个商品聚合在一起。而且未来，可能会有新的需求导致第三种甚至第四种合集类型的出现，例如可能会新增一种主要由规则生成同时允许手工加入商品的合集类型。但无论需求怎么变更，有一点是不会变的——它们从逻辑上永远是一种用于将若干个商品聚合在一起的功能。因此或许我们可以进一步的这样重构：

type Collection {
  [CollectionRule]
  Image
  [Product]
}

type CollectionRule { }

这样就看起来简洁多了，也许你会担心对于手动合集而言，聚合规则（CollectionRule）字段是不存在的。但实际上只要返回一个空数组，那么这一设计完全是符合逻辑和满足需求的。

结论

在较高的抽象层级下进行 API 设计，要求你必须对于你所建模的业务场景有着非常深刻的认知。不要急于进行细节实现，花费足够时间理解业务场景及其上下文对于你而言至关重要。

与此同时，一个好的 API 设计也不应该是对于某个 UI 设计稿的建模——你不应该在设计 API 时只考虑设计稿中要求体现哪些字段。即便 UI 设计稿和数据库表结构对于 API 设计而言非常有参考价值，但你务必记得你的核心关注点应该是更为抽象的业务场景。

更重要的是，务必不要照搬现有的 REST API 设计（如果有的话）。REST 和 GraphQL 背后是不同的思考逻辑，你在 REST API 领域的设计经验对于 GraphQL API 而言未必是能够适用的。

既往不恋，纵情向前，当下不杂，未来不迎。

规则三：围绕着业务背景重新思考你的 GraphQL API，切忌直接照搬数据库表结构、视觉稿或已有的 REST API。

步骤 3: 增加细节

现在我们已经有了一个大体合适的抽象模型，我们可以逐步开始考虑细节——把隐去的具体字段加回来。

在我们开始增加每一个字段时，我们都需要仔细思考这个字段是否真的有存在的必要。我们的 GraphQL 类型中存在某个字段是因为我们的业务场景需要用到，而不应该是因为这个字段在数据库中存在或在过去的 REST API 中存在。

在 GraphQL 中暴露一个字段、参数或类型，非常简单。但一旦发布上线后，你想要将之去除和改名将变得异常苦难，GraphQL 的灵活意味着你很难预测哪些地方会用到它们。

规则四：永远记得在 GraphQL 中去掉一个字段要比新增一个字段困难的多。

最初实现

如果不逐一考虑每个字段存在的必要性而是先全部加回来的话，那么当前的 GraphQL Schema 大概是这样的：

type Collection {
  id: ID!
  rules: [CollectionRule!]!
  rulesApplyDisjunctively: Boolean!
  products: [Product!]!
  title: String!
  imageId: ID
  bodyHtml: String
}

type CollectionRule {
  column: String!
  relation: String!
  condition: String!
}

接下来，我们来从上到下具体思考每一个字段是否有其存在的必要。

ID 和 `Node` 接口

在我们的合集类型中，第一个字段是 ID 字段。非常合理，而且确实是必须的——我们在做增删该查时都会用的到这一字段。不过，在 GraphQL API 中往往会存在一个Node 接口，它的具体结构如下：

interface Node {
  id: ID!
}

在 GraphQL 中，它用来告示客户端基于其实现的对象是可以基于唯一 ID 进行持久化和搜索的，这有助与客户端更高效的实现本地缓存和其他功能。

译者注：Node 接口实际上 Relay 规范的一部分，可以在 GraphQL Sever Specification 中了解具体信息。

因此我们的业务对象应该继承于 Node接口：

type Collection implements Node {
  id: ID!
}

规则五：绝大多数业务对象都应该集成自 Node 接口。

`Rules` 字段和子对象

接下来我们开始审视 rules 和 rulesApplyDisjunctively 这两个字段。

第一个字段 rules 非常直观，返回一个包含自动匹配规则的列表。不过请注意，这一字段并标记为了非空字段——这是一个不错的设计。在 GraphQL 中 null、[] 和 [null]是不同的，因此这一设计有助于我们确保当合集的类型是手动合集时 rules 的值可以为 []，但不能为 null 或者 [null]。

小贴士：一个空数组和null在逻辑上有着不同的语义。

第二个字段 rulesApplyDisjunctively 返回的是布尔值——用来表示rules数组中的多条规则之间是取交集还是并集（or 还是 and）。但对于不适用于规则的手动合集而言，这一字段的值应该是什么似乎是个问题。

对此而言，引入一种的 GraphQL 类型——CollectionRuleSet可能是个好的选择。当你在同一 GraphQL 类型中有一组值和行为密切相关的字段时，将他们单独抽出来作为一个新的类型往往是很有必要的，因为这可以避免语义上出现歧义。对于我们现在关注的这一场景而言，采用如何下的设计可以确保允许 CollectionRuleSet 为空并同时保证布尔类型的 appliesDisjunctively 字段的非空性：

type Collection implements Node {
  id: ID!
  ruleSet: CollectionRuleSet
  products: [Product!]!
  title: String!
  imageId: ID
  bodyHtml: String
}

type CollectionRuleSet {
  rules: [CollectionRule!]!
  appliesDisjunctively: Boolean!
}

type CollectionRule {
  column: String!
  relation: String!
  condition: String!
}

小贴士：确保布尔类型的字段永远是非空的。如果你想要一种允许为空的布尔类型，请确保该字段的（空/真/假）三种状态在语义上存在区别的并请务必三思

规则六：将同一类型中互相密切相关的几个字段单独抽出来作为子对象。

列表和分页

接下来我们开始关注 products 字段，这个字段看起来是合理的——毕竟我们在移除CollectionMembership以及梳理它的关联逻辑，但实际这里还是存在着一些问题。

从语义上来说，该字段返回的是一个包含集合中所有商品的数组——一个集合中可能包含着成千上万款商品。直接罗列全部商品显然是非常低效和代价高昂地，因此我们非常有必要考虑分页问题。

请记得在设计 GraphQL API 时，一旦遇到数组数字就记得考虑下其是否存在分页的必要。尤其是，记得确认下在真实的业务场景中，这一数字通常会包含多少个元素。

在 GraphQL API 中实现分页功能存在着许多不同的设计方案。本教程中使用的是由 Relay Connection spec 所提出的 Connections 方案。

对我们的业务场景来说，将商品字段重新定义为 products: ProductConnection! 即可实现分页——假设你已经实现了 Relay 规范中所定义的 Connections 的话：

type ProductConnection {
  edges: [ProductEdge!]!
  pageInfo: PageInfo!
}

type ProductEdge {
  cursor: String!
  node: Product!
}

type PageInfo {
  hasNextPage: Boolean!
  hasPreviousPage: Boolean!
}

规则七：始终记得检查数组字段是否有必要支持分页。

字符串

接下来我们开始关注 title字段，它的设计完全没有问题。考虑到业务上要求所有合集都有 1 个名字，所以它被标记为非空是合理的。

小提升：在 GraphQL 中 "" 和 null 是不同的——就像前述的 [] 、[null] 和 null一样。因为从逻辑上来说，它们有着不同的语义：”“意味着这个字段是存在的，只是恰好值是空白的，而null则意味着这个字段对于当前实例来说是不适用的。

关联对象的 ID

接着是 imageId 字段，这个字段是一个用来说明如果你完全把 REST API 的设计照搬到 GraphQL 中会发生什么的典型例子。在 REST API 中返回其他对象的 ID 是非常常见的行为，但在 GraphQL 中这是一个反模式。因为仅提供其他对象的 ID，意味着我们需要再发起一条新的 GraphQL 查询来查找它们。在 GraphQL 中服务器会仅返回查询中显式列出的字段而不是一股脑的返回该对象所包含的所有字段，因此不必像 REST API 那样担心返回的冗余字段过多。

作为普遍性规则，我们通常在 GraphQL Schema 设计中尽可能地返回它的关联对象而不仅是关联对象的 ID：

type Collection implements Node {
  id: ID!
  ruleSet: CollectionRuleSet
  products: ProductConnection!
  title: String!
  image: Image
  bodyHtml: String
}

type Image {
  id: ID!
}

type CollectionRuleSet {
  rules: [CollectionRule!]!
  appliesDisjunctively: Boolean!
}

type CollectionRule {
  column: String!
  relation: String!
  condition: String!
}

规则八：尽可能直接返回关联对象本身而不是仅仅返回关联对象的 ID。

命名与标量（Scalar）

最后，我们来关注下 Collection 类型中的 bodyHtml 字段。对于一个不熟悉技术细节的用户而言，这个字段名可能会存在歧义，因此将之改名为 description 会是更为合理的选择。

规则九：给字段起名时尽可能体现其在业务上的语义，而不是简单照搬数据库中的字段名。

另外，我们其实应该思考下 String 对于这个字段而言是否是合理的类型。GraphQL 内置了一些标量类型（例如： String、Int、Boolean 等等），但与此同时它也允许你定义更多的标量类型。基于我们的场景自定义一个叫做 HTML的标量类型，来说明这个字段的值应该是有效的 HTML 片段，要比直接把它视为一个叫做 bodyHtml 的字符串字段更为符合语义。

不过每当你想要添加一个标量字段时，请记得先检查下现有的自定义标量字段中是否已经存在符合语义的选择。如果计划增加一个新的标量类型，最好确保和团队中其他成员达成共识。

规则十：使用自定义的标量类型，有助于更好地说明字段隐含的上下文。

分页的再思考

审视完 Collection 之后，我们接下来思考下 CollectionRuleSet 类型作为一个数组是否有进行分页的必要。

虽然在大多数场景下分页是必要的，但就 CollectionRuleSet 而言分页却会是一个极低性价比的选择。因为通常来说一个集合中往往之后包含极少数的规则，甚至对于手动集合来说这直接会上一个空数组。

枚举（Enum）

CollectionRule 类型有着 column、relation、condition 三个字段，分布表示要匹配的属性（值如商品表的 title字段）、操作符（例如可能是 = 或者 start_with）以及期望的值。

考虑到 column 是一个数据库术语，因此我们先把这个字段重新命名为 GraphQL 术语—— field 会比较符合语义。

接下来，由于 fields 和 relation 这两个字段的值完全是能够枚举的，我们可以在 GraphQL 中用枚举类型实现它们来确保 API 拥有更高的健壮性：

type Collection implements Node {
  id: ID!
  ruleSet: CollectionRuleSet
  products: ProductConnection!
  title: String!
  image: Image
  description: HTML!
}

type CollectionRuleSet {
  rules: [CollectionRule!]!
  appliesDisjunctively: Boolean!
}

type CollectionRule {
  field: CollectionRuleField!
  relation: CollectionRuleRelation!
  value: String!
}

enum CollectionRuleField {
  TAG
  TITLE
  TYPE
  INVENTORY
  PRICE
  VENDOR
}

enum CollectionRuleRelation {
  CONTAINS
  ENDS_WITH
  EQUALS
  GREATER_THAN
  LESS_THAN
  NOT_CONTAINS
  NOT_EQUALS
  STARTS_WITH
}

规则十一：对于值可以被穷举的字段，尽可能使用枚举类型。

步骤 4: 商业逻辑

我们现在已经有了一个基本可用且设计良好的 GraphQL Schema。即便像如何处理商品排序之类的细节问题还没有处理，但完全可以照着前文列出的规则来逐一实现。接下来，我们需要做的是审视现有的 API 设计是否完全满足了产品需求。

在这一步骤中最为简单的思考方式或许是——想象下假设你同时需要使用这些 API 来开发客户端，那么对于实现客户端中的功能而言目前所能提供的 API 是否能够满足需求。

不过这种思考范式存在着一些问题——对于大规模应用或者对外提供公开 API 的应用来说，你很难想象客户端中的哪些功能会用到这一接口。一个 GraphQL Type 应该是为很多种不同客户端的很多种不同业务场景提供服务的，你必须同时兼顾到其通用性。因为通用性不足导致的接口冗余意味着额外的工作量和更多的出错概率。

规则十二：GraphQL API 提供的应该是业务逻辑而非数据。尽可能把业务逻辑放在 API 中实现，而非任由各个客户端自行实现。

例如对于我们的例子而言，很有必要实现如下的方法：

type Collection implements Node {
  # ...
  hasProduct(id: ID!): Boolean!
}

其用于帮助判断某一商品是否在合集中存在。不同于 Rest API，在 GraphQL 中某个类型存在大量的辅助字段（或方法）不会带来任何的额外开销。

不过也请注意，即便我们可能尽可能多地提供辅助字段但我们不可能穷举出所有的使用场景。因此提供辅助字段的同时，请千万不要将原始数据隐藏起来。

译者注：也就是说假设 User 类型存在 lastName 和 firstName，额外提供 1 个 fullName 字段很有帮助，但这不意味着你可以只提供 fullName 字段。

规则十三：记得同时提供原始字段与业务相关的计算字段。

最后，如果在基于业务逻辑设计 GraphQL API 时发现现有的数据库结构或底层实现难以满足，那么不要因此对业务模型有所妥协。一切都应该为业务模型服务的，你可能要做的是改动你的数据库结构或技术实现。

步骤 5: 变更（Mutation）

我们现有的 GraphQL Schema 只满足了查询需求，接下来我们需要来设计一些 Mutation 以满足对于合集进行创建、修改和删除的需求。

如同我们在一开始进行 Query 设计时一样，我们先从更高的抽象层级开始思考——这意味着我们先去思考我们需要实现哪些种类的变更，而先不考虑每种 Mutation 的具体实现细节。

最为「大力出奇迹」的思路是——照着 CRUD 的范式我们给所有需要的类型都创建 增、删、改 三种形式的变更。在 REST API 中这是不错的选择，但对于 GraphQL API 来说这样做是远远不够用的。

根据具体业务来划分支持的操作种类

你可能会注意到如果仅按照 CRUD 范式来做的话，用于实现更新操作的 Mutation 会变得极为臃肿且承担了太多职能：

更新合集的名称或描述
设置合集生效与否（publish/unpublish）
修改规则
添加、移除、重新排序商品

等等。这样的设计对于服务器端和客户端来说显然都是一种麻烦的困扰。因此将 GraphQL Mutation 拆分成更细粒度会是个好主意。比方说，我们可以想把 publish和unpublish 作为两种不同的操作给拆分出来：

create
delete
update
publish
unpublish

规则十四：根据真实的业务需要思考 GraphQL 类型支持哪些种类的操作

思考对象与对象间的关系

在我们拆出 publish & unpublish 之后，update Mutation 仍然显得非常臃肿因此有必要做进一步的拆分。，我们可以从对象与对象间的关系作为思考的切入点。具体到商品与合集直接的关系，我们可以作出如下结论：

按照 CRUD 范式，当我们需要改变合集中所保护的商品就需要提供一个新的商品数组（形如 products: [ProductInput!]!），但假设某一集合中包含了非常多种商品，显然这样做会存在不小的性能问题。
为了实现增量更新，在 update Mutation 中提供诸如 productsToAdd: [ID!]! 、productsToReorder: [ID!]! 和 productsToRemove: [ID!]! 的字段会是一个好的选择。
但与其将之作为 update 的 3 个 input 字段，直接将它们拆分成 3 个新的 Mutation 显然会来的更为简单直观。

不过当我们将上述原则用于其他的场景时，请记得考虑如下问题而不是教条地照搬：

这个数组是否需要分页？对于小数组而言，提供单独的增量更新很可能是一种过度设计。
数组中包含的元素是否拥有自己的 ID？例如在合集和合集规则的关系中，CollectionRule 类型并没有 id 字段。因此它并不应该被抽离成单独的 Mutation。

规则十五：设计 Mutation 很复杂，不能教条式地进行照搬。

在完成上述改动之后，现在我们拥有这些 Mutation:

create
delete
update
publish
unpublish
addProducts
removeProducts
reorderProducts

你可能已经注意到了和商品相关的那 3 个 Mutation 都是复数，因为如果我们能够提供在统一合集内同时增加或删除多个商品的方法，显然能满足更多地客户端实际使用场景——除非 PRD 中明确禁止我们这么做。

规则十六：尽可能让 Mutation 支持批量操作。

Input: 结构 - 第一部分

在明确了我们需要实现哪些 Mutation 之后，我们还需要明确下每个 Mutation 要支持的入参（Input）有哪些。如果你看过其他人写的 GraphQL Schema，你可能会注意到很多 Mutation 统称都只定义了一个名叫 input 的入参并单独为之定义了一个全局唯一的 Input 类型来描述它实际所需要的入参。实际上这是传统的 Relay 客户端（Relay Classic API）所要求遵循的规范，我们不建议你在新代码中继续遵循这种约定。

对于一些简单的 Mutation 而言提供 ID 或 ID 数组就完全足够了，比方说delete、publish 和 removeProducts 等等。

我们只需要重点考虑下述 3 个 Mutation 的 Input 要如何设计：

create
update
reorderProducts

首先是 create。仍旧是先写一个「大力出奇迹」的版本出来：

type Mutation {
  collectionDelete(collectionId: ID!)
  collectionPublish(collectionId: ID!)
  collectionUnpublish(collectionId: ID!)
  collectionAddProducts(collectionId: ID!, productIds: [ID!]!)
  collectionRemoveProducts(collectionId: ID!, productIds: [ID!])
  collectionCreate(title: String!, ruleSet: CollectionRuleSetInput, image: ImageInput, description: HTML!)
}

input CollectionRuleSetInput {
  rules: [CollectionRuleInput!]!
  appliesDisjunctively: Boolean!
}

input CollectionRuleInput {
  field: CollectionRuleField!
  relation: CollectionRuleRelation!
  value: String!
}

你可能注意到这些 Mutation 的名字都是以形如 类型-行为(例如 collectionDelete) 而非 行为-对象 (例如 deleteCollection) 的形式命名，即便后者更符合英文语法。

这是因为 GraphQL 目前没有提供对于 Mutation 进行分组的办法，因此将类型前置有助于我们在 Schema 中更显眼的看到某一类型支持哪些种类的 Mutation。

*规则十七：使用形如 orderCancel 而不是 cancelOrder的命名风格来个 Mutation 命名 *

Input: 标量

在现有的方案中 description 字段存在这几个问题，首先我们有必要将其设为允许为空。即便是同一类型其被作为 Mutation 的 Input 时和在 Query 中调用时，其是否必填可能是不一致的。需要根据实际情况仔细审视。 规则十八：仅将真的必填的字段在 Input 中设为必填

我们还需要根据实际情况审视descripition的数据类型，例如我们很可能允许用户在输入时仅提供 String 而不是 HTML 片段，而由服务器端在将之保存到数据库前从字符串格式化为 HTML 片段。因此除非你希望这一字符串到 HTML 片段的格式化逻辑在客户端实现，否则 String 会是个更好的选择。

规则十九：当 Input 类型比较复杂导致客户端进行验证过于复杂时，可以将之弱化成更通用的类型以便于由服务器进行验证。例如用 string 标量替代 email 标量，然后在服务器端进行验证并将所有的错误提示一次性返回给客户端。

但需要注意的是，这并不是要求你在所有场景下都对输入值使用更弱的类型。例如在本教程的例子中 field 和 relation 的值显然必须依然是枚举类型。此外诸如 DateTime 之类的类型显然也不应该被弱化成字符串。关键的区别因素的客户端进行强类型验证的成本以及格式本身的模糊性。

规则二十：当输入的格式可能有歧义而且客户端验证并不困难的时候，应该有限考虑使用强类型（例如 DateTime 优于 String）

Input: 结构 - 第二部分

接下来我们把关注点放在 update Mutation 上：

type Mutation {
  # ...
  collectionCreate(title: String!, ruleSet: CollectionRuleSetInput, image: ImageInput, description: String)
  collectionUpdate(collectionId: ID!, title: String, ruleSet: CollectionRuleSetInput, image: ImageInput, description: String)
}

你会注意到，这与我们的 create Mutation 非常相似，但有两个不同之处：增加了一个 collectionId 参数，它决定了要更新哪个合集同时title不再是必需的，因为title可能不需要被更新。即便不算上允许为空的 title，在 create 和 update 中有四个 Input 参数是重复的。

考虑到「DRY（不要重复你自己）」原则，我们觉得在 create 和 update Mutation 共享一部分逻辑会是更好的选择：

type Mutation {
  # ...
  collectionCreate(collection: CollectionInput!)
  collectionUpdate(collectionId: ID!, collection: CollectionInput!)
}

input CollectionInput {
  title: String
  ruleSet: CollectionRuleSetInput
  image: ImageInput
  description: String
}

尽管这样一来 create 时的 title 也变成了允许为空，但如果需要的话我们完全可以在 create 的 resolver 中再行验证。

规则二十一：结构化 Mutation 的 Inpute 以减少重复，即使是以在类型层面上放宽对于某些字段的要求性约束为代价。

Mutation 的返回值

我们需要处理的最后一个设计问题是 Mutation 的返回值。通常情况下，Mutation 是可能成功但也可能报错，虽然 GraphQL 确实包含了对查询层面错误的明确支持，但这些错误对于业务层面的 Mutation 报错来说并不够用。因此每个 Mutation 都应该定义一个包含有用户错误字段的 "payload " 类型。对于create 来说，它可能是这样的：

type CollectionCreatePayload {
  userErrors: [UserError!]!
  collection: Collection
}

type UserError {
  message: String!

  # Path to input field which caused the error.
  field: [String!]
}

对于执行成功的 Mutation，它将返回一个空的 UserErros 数组，和一个包含了新加入商品的 collection 数组。而执行失败的 Mutation 则恰恰与之相反。

规则二十二：Mutation 的中应该包含一个标识业务层面错误的数组。

对与 update 来说也是相似的：

type CollectionUpdatePayload {
  userErrors: [UserError!]!
  collection: Collection
}

值得注意的是，即使是在update里 Payload 的 collection仍然是可空的，因为如果提供 input 中提供的 ID 数组不代表一个有效的集合，就没有要返回的集合。

规则二十三：大多数的 Payload .字段都应该是可以为空的，除非确保其在错误的情况下也有返回值。

TLDR: 设计准则总结

规则一：永远先从更高的抽象层级进行设计，先考虑类型与类型之间的关系，再去考虑具体的字段。
规则二：永远不要在 API 中暴露不必要的实现细节。
规则三：围绕着业务背景重新思考你的 GraphQL API，切忌直接照搬数据库表结构、视觉稿或已有的 REST API。
规则四：永远记得在 GraphQL 中去掉一个字段要比新增一个字段困难的多。
规则五：绝大多数业务对象都应该集成自 Node 接口。
规则六：将同一类型中互相密切相关的几个字段单独抽出来作为子对象。
规则七：始终记得检查数组字段是否有必要支持分页。
规则八：尽可能直接返回关联对象本身而不是仅仅返回关联对象的 ID。
规则九：给字段起名时尽可能体现其在业务上的语义，而不是简单照搬数据库中的字段名。
规则十：使用自定义的标量类型，有助于更好地说明字段隐含的上下文。
规则十一：对于值可以被穷举的字段，尽可能使用枚举类型。
规则十二：GraphQL API 提供的应该是业务逻辑而非数据。尽可能把业务逻辑放在 API 中实现，而非任由各个客户端自行实现。
规则十三：记得同时提供原始字段与业务相关的计算字段。
规则十四：根据真实的业务需要思考 GraphQL 类型支持哪些种类的操作。
规则十五：设计 Mutation 很复杂，不能教条式地进行照搬。
规则十六：尽可能让 Mutation 支持批量操作。
规则十七：使用形如 orderCancel 而不是 cancelOrder的命名风格来个 Mutation 命名。
规则十八：仅将真的必填的字段在 Input 中设为必填。
规则十九：当 Input 类型比较复杂导致客户端进行验证过于复杂时，可以将之弱化成更通用的类型以便于由服务器进行验证。例如用 string 标量替代 email 标量，然后在服务器端进行验证并将所有的错误提示一次性返回给客户端。
规则二十：当输入的格式可能有歧义而且客户端验证并不困难的时候，应该有限考虑使用强类型（例如 DateTime 优于 string）。
规则二十一：结构化 Mutation 的 Inpute 以减少重复，既是是以在类型层面上放宽对于某些字段的要求性约束为代价。
规则二十二：Mutation 的中应该包含一个标识业务层面错误的数组。
规则二十三：大多数的 Payload .字段都应该是可以为空的，除非确保其在错误的情况下也有返回值。

结尾

感谢你阅读我们的教程。希望它有助于你设计一个好的 GraphQL API。

null

cn_boris — Mon, 06 Apr 2020 15:50:35 +0800

null

[绍兴柯桥 / 杭州萧山] 有数派诚聘 Ruby 后端、React、React Native 前端工程师 / 长期有效 ( 15K - 30K )

cn_boris — Tue, 05 Nov 2019 12:42:04 +0800

什么是有数派？

有数派 ( https://youshupai.com ) 是

国内领先的纺织产业互联网践行者，我们为纺织贸易 / 工业企业提供软硬件结合的 SaaS 解决方案帮助传统企业对内提升企业运营效率对外依靠大小数据结合的方式链接产业上下游并提供 B2B 交易服务。

目前产品功能覆盖了交易、⽣产、质检、仓储、工业控制 ( 物联网 ) 等业务场景，终端覆盖了 TV、手机、PC、iPad、PDA 等设备，我们通过 SaaS 工具提升纺织企业交易/运营效率，同时通过实时数据监控、数据可视化、数据分析和数据追溯协助企业做业务决策，用数据驱动业务增长。

系统目前管理了⼏十亿的⾯料交易订单与几亿匹的布匹数据。UGG、Zara、海澜之家、七匹狼、Tommy、CK 等几十家知名服装厂商的面料供应商都在使用我们的产品。

融资情况？

我们已经获得一线的美元基金贝塔斯曼亚洲投资基金（BAI）和真格基金的各数百万美元风险投资，其也是 UCloud、Keep、摩拜、哈罗单车、拉钩、寺库、网易云音乐等知名互联网公司的投资人

相关媒体报道：

36 氪首发｜36 氪首发｜纺织业 SaaS「有数派」完成数百万美元 A 轮融资，由真格基金独家投资 - [36氪首发｜纺织业SaaS「有数派」完成数百万美元A轮融资，由真格基金独家投资](https://36kr.com/p/5243898)
36 氪首发｜纺织业 SaaS「有数派」完成数百万美元 Pre-A 轮融资，BAI 独家投资 - [36氪首发｜纺织业SaaS「有数派」完成数百万美元Pre-A轮融资，BAI独家投资](https://36kr.com/p/5230465)
自主研发了技术架构 + 设计模式，有数派要帮助纺织企业更好地进行管理与运营 - [自主研发了技术架构+设计模式，有数派要帮助纺织企业更好地进行管理与运营](https://www.lieyunwang.com/archives/446073)
当互联网嵌入传统纺织业，有数派想以 SaaS 工具切入 B2B 交易 - [当互联网嵌入传统纺织业，有数派想以SaaS工具切入B2B交易](https://36kr.com/p/5148992)

我们的工程师团队：

目前我们的研发团队一共有 40 多位同事

前端（React Native + React + iOS & Android）10 + 位

后端（纯后端 Ruby）10 + 位

产品 & 设计若干

我们来自：

华兴资本、Tower、搜狐、阿里巴巴、华为、京东、美团、挖财、大搜车、多伦多大学、西北大学、湖南大学、电子科技大学等一线互联网公司与高等学府。

同时我们也赞助了今年上海的 RubyConf 活动

我们的技术栈：

全套 GraphQL + Ruby on rails + PG + React + React Native + MQTT（IoT） .

我们可能是国内为数不多在后端架构上全套使用 GraphQL 技术的公司，目前用 GraphQL 支撑了 6 个客户端的业务覆盖了近 200 个 Model。

团队撰写了国内第一本 GraphQL 中文书籍（即将出版） & GraphQL 布道者

杭州第一届 GraphQLParty - [杭州第一届 GraphQLParty](http://www.huodongxing.com/event/7441170737900?from=groupmessage)

我们在找什么样的人

Ruby 工程师

【基础要求】

0、相信产业互联网的机会，并愿意投身传统行业改造浪潮的工程师

1、3 年以上 Ruby on Rails 开发经验；

2、具有扎实的语言基础，良好的面向对象编程思想；

3、掌握常用的设计模式，了解移动互联网相关技术；

4、熟悉 Linux 类环境，能熟练使用 Unix 类系统下的 ruby 编程；

5、熟悉 MYSQL、PG 或其他大型数据库，能够快速根据需求完成高性能数据库设计，有大负载高可靠设计经验；

【加分项】

1、有 Iot 工业产品或大规模数据应用开发经验者加分

2、对前端技术有一定的应用者大大加分（React 方向）

3、对 GraphQL 技术栈有一定的研究或者应用者大大加分

【薪资 & HeadCount】

薪资范围：15k - 30k

本次招聘 5 位后端工程师

React 工程师

【基础要求】

0、相信产业互联网的机会，并愿意投身传统行业改造浪潮的工程师

1、3 年以上前端开发经验，精通各种 Web 前端的原理及技术；

2、精通 React 全家桶，对 React, Redux 等源码及核心技术有一定的研究和自己的理解；

3、对前端组件化和工程化有一定经验，熟悉 webpack，了解其原理并能进行一定的开发工作；

4、熟悉函数式编程，熟悉 ES6 规范，掌握常用的 JS 设计模式，有良好的编码风格；

5、对前端前沿技术保持热情的态度，例如 React Hooks, React Fiber，SSR 等；

【加分项】

1、有 Iot 工业产品或复杂企业后台应用开发经验者加分

2、有小程序开发经验者加分

3、对后端技术有实际项目开发经验者加分（Ruby 方向）

4、对 GraphQL 技术栈有一定的研究或者应用者大大加分

【薪资 & HeadCount】

薪资范围：15k - 30k

本次招聘 3 位 React 前端工程师

React Native 工程师

0、相信产业互联网的机会，并愿意投身传统行业改造浪潮的工程师

1、3 年以上前端开发经验，1 年以上 React Native 开发经验，熟练掌握各种 Web 前端的原理及技术；

2、熟悉 React 和 React Native 基本工作原理，有完整参与或主导过一个 React Ntive 实际项目开发经验；

3、有一定 Android 或 iOS 原生研发能力；

4、熟悉函数式编程，熟悉 ES6 规范，掌握常用的 JS 设计模式，有良好的编码风格；

5、熟悉 React Native 性能优化

【加分项】

1、有 Iot 工业产品或复杂企业后台应用开发经验者加分

2、有丰富的原生开发经验者加分（Android 或 iOS）

3、对后端技术有实际项目开发经验者加分（Ruby 方向）

4、对 GraphQL 技术栈有一定的研究或者应用者大大加分

【薪资 & HeadCount】

薪资范围：15k - 30k

本次招聘 2 位 React Native 前端工程师

与我联系

[北京][实习] Oortcast 招聘 SDE Intern

cn_boris — Mon, 21 Oct 2019 22:20:59 +0800

技能要求

拥有强烈的求知欲与好奇心，相信「个体能够通过创造力推动世界变得更好」；
熟悉 TypeScript 或 EcmaScript 6；
基本掌握右列 Web 前端技术栈的一种或多种：React、Immutable.js、Web Components、RxJS、Vue、Angular 9；
基本掌握右列语言中的一种或多种：Rust、Ruby、Python、Perl、Lisp / Clojure、Go、Scala、Haskell；
熟悉常用的数据结构，对动态规划、分治、回溯等常用算法有基本的了解；
了解右列技术中一种或多种者优先：WebAssembly、GraphQL、PostgreSQL、Kubernetes、Solid、RDF；
足够聪明或有能力让我们觉得你足够聪明。

岗位收益

200 - 400 元/ 天的薪资，视乎能力而定；
参与知识图谱与 Web 3.0 领域的前沿创新，与世界级的团队一起参与世界级的项目，提升个人视野与能力极限；

工作地点

北京市朝阳区

与我们联系

careers{at}oortcast.com

我们是谁

Oortcast 为试图改变世界的创业公司和创意工作者提供效率工具、解决技术难题。我们的开源项目——42Page，旨在通过重新定义「文档」软件的形态来指数级提升创意工作者的生产力。

我们的价值观

科技向善的市井雄心

我们相信收入并不仅仅只是货币，它还包括「我们在致力于让世界变得更好的过程中所能够收获到的成就感与影响力」。

绝不重复你自己

有人说认为花大量的时间做自动化的工具，还不如人肉的效率高，比如，写自动化的脚本花 5 个小时，而重复做这件事 200 次只花 3 个小时。有这样的理解的人根本不懂工程。一方面，这个工具可以共享重用，更多的人可以从中受益，这次我花 5 个小时开发这个工具，下次只用 1 小时改一下就可以用在别的地方，这是着眼于未来而不是眼下的成本。更重要的是，这是一种文化，一种提高效率的文化，他会鼓励和激发出更多的这样的事情发生。摘录自什么是工程师文化？ - 陈皓

我们认为工程师文化的精髓并不在于无限量的零售或者有意思的文化衫（尽管这两者其实我们都提供 XD），而在于「发现根本原因彻底解决问题」。具体而言我们：

残酷无情的推进自动化 你的时间必需花费在最具创造力的事务上。对我们而言，生产力工具与用户产品同等重要。
保持克制 复杂系统意味着更多的熵，我们倾向于优先考虑更简洁的解决方案。同时也意味着，在能满足需求的情况下理应优先考虑现有的 SaaS 产品或基于开源项目。
持续改善 我们极度重视回顾会议，并对所发现的问题寻求根本性的解决。

人人都是斜杠青年

做一个异端是有回报的，不仅是在科学领域，在任何有竞争的地方，只要你能看到别人看不到或不敢看的东西，你就有很大的优势。训练自己去想那些不能想的事情，你获得的好处会超过所得到的想法本身。如果自己就是潮水的一部分，怎么能看见潮流的方向呢？你只能永远保持质疑。问自己，什么话是我不能说的？为什么？摘录自《黑客与画家》- Paul Graham TRIZ 理论认为，产品创新的标志是解决或移走设计中的冲突，而产生新的有竞争力的解。设计人员在设计过程中不断的发现并解决冲突是推动产品进化的动力。

很大程度上跨学科的知识，通过类比往往可以发挥 1+1 › 2 的效率，从而有力的解决设计中的冲突。 设计（Design）的词源最早可以被追溯到拉丁文的 de(tomake) 和 signare(mark), 意即制造某一事务并将之符号化从而赋予其与众不同的意义。无论我们的大脑之于真实世界或者系统架构之于赛博世界，符号化本身的抽象意味都是在复杂系统中解构「熵」的重要方式。架构的本质不外乎寻求合适的切入点进行恰到好处的抽象以便复杂度得到有效的管理。

因而我们往往能够从诸如建筑、法学、经济学等等「设计性」领域获取到新的架构养分与启迪。例如众所周知的「设计模式」概念最早来源于建筑学。我们鼓励团队成员学习专业领域以外的事物，包括但不限于：通识知识和社会科学。我们也将尽可能的为团队成员学习这些能力提供支持与便利。

[绍兴柯桥 / 杭州萧山] 有数派诚聘 Ruby 后端、React、React Native 前端工程师 / 长期有效 ( 15K - 30K )

cn_boris — Thu, 29 Aug 2019 10:45:28 +0800

什么是有数派？

有数派 ( https://youshupai.com ) 是

融资情况？

相关媒体报道：

36 氪首发｜36 氪首发｜纺织业 SaaS「有数派」完成数百万美元 A 轮融资，由真格基金独家投资 - [36氪首发｜纺织业SaaS「有数派」完成数百万美元A轮融资，由真格基金独家投资](https://36kr.com/p/5243898)
36 氪首发｜纺织业 SaaS「有数派」完成数百万美元 Pre-A 轮融资，BAI 独家投资 - [36氪首发｜纺织业SaaS「有数派」完成数百万美元Pre-A轮融资，BAI独家投资](https://36kr.com/p/5230465)
自主研发了技术架构 + 设计模式，有数派要帮助纺织企业更好地进行管理与运营 - [自主研发了技术架构+设计模式，有数派要帮助纺织企业更好地进行管理与运营](https://www.lieyunwang.com/archives/446073)
当互联网嵌入传统纺织业，有数派想以 SaaS 工具切入 B2B 交易 - [当互联网嵌入传统纺织业，有数派想以SaaS工具切入B2B交易](https://36kr.com/p/5148992)

我们的工程师团队：

目前我们的研发团队一共有 40 多位同事

前端（React Native + React + iOS & Android）10 + 位

后端（纯后端 Ruby）10 + 位

产品 & 设计若干

我们来自：

同时我们也赞助了今年上海的 RubyConf 活动

我们的技术栈：

全套 GraphQL + Ruby on rails + PG + React + React Native + MQTT（IoT） .

我们可能是国内为数不多在后端架构上全套使用 GraphQL 技术的公司，目前用 GraphQL 支撑了 6 个客户端的业务覆盖了近 200 个 Model。

团队撰写了国内第一本 GraphQL 中文书籍（即将出版） & GraphQL 布道者

杭州第一届 GraphQLParty - [杭州第一届 GraphQLParty](http://www.huodongxing.com/event/7441170737900?from=groupmessage)

我们在找什么样的人

Ruby 工程师

【基础要求】

0、相信产业互联网的机会，并愿意投身传统行业改造浪潮的工程师

1、3 年以上 Ruby on Rails 开发经验；

2、具有扎实的语言基础，良好的面向对象编程思想；

3、掌握常用的设计模式，了解移动互联网相关技术；

4、熟悉 Linux 类环境，能熟练使用 Unix 类系统下的 ruby 编程；

5、熟悉 MYSQL、PG 或其他大型数据库，能够快速根据需求完成高性能数据库设计，有大负载高可靠设计经验；

【加分项】

1、有 Iot 工业产品或大规模数据应用开发经验者加分

2、对前端技术有一定的应用者大大加分（React 方向）

3、对 GraphQL 技术栈有一定的研究或者应用者大大加分

【薪资 & HeadCount】

薪资范围：15k - 30k

本次招聘 5 位后端工程师

React 工程师

【基础要求】

0、相信产业互联网的机会，并愿意投身传统行业改造浪潮的工程师

1、3 年以上前端开发经验，精通各种 Web 前端的原理及技术；

2、精通 React 全家桶，对 React, Redux 等源码及核心技术有一定的研究和自己的理解；

3、对前端组件化和工程化有一定经验，熟悉 webpack，了解其原理并能进行一定的开发工作；

4、熟悉函数式编程，熟悉 ES6 规范，掌握常用的 JS 设计模式，有良好的编码风格；

5、对前端前沿技术保持热情的态度，例如 React Hooks, React Fiber，SSR 等；

【加分项】

1、有 Iot 工业产品或复杂企业后台应用开发经验者加分

2、有小程序开发经验者加分

3、对后端技术有实际项目开发经验者加分（Ruby 方向）

4、对 GraphQL 技术栈有一定的研究或者应用者大大加分

【薪资 & HeadCount】

薪资范围：15k - 30k

本次招聘 3 位 React 前端工程师

React Native 工程师

0、相信产业互联网的机会，并愿意投身传统行业改造浪潮的工程师

1、3 年以上前端开发经验，1 年以上 React Native 开发经验，熟练掌握各种 Web 前端的原理及技术；

2、熟悉 React 和 React Native 基本工作原理，有完整参与或主导过一个 React Ntive 实际项目开发经验；

3、有一定 Android 或 iOS 原生研发能力；

4、熟悉函数式编程，熟悉 ES6 规范，掌握常用的 JS 设计模式，有良好的编码风格；

5、熟悉 React Native 性能优化

【加分项】

1、有 Iot 工业产品或复杂企业后台应用开发经验者加分

2、有丰富的原生开发经验者加分（Android 或 iOS）

3、对后端技术有实际项目开发经验者加分（Ruby 方向）

4、对 GraphQL 技术栈有一定的研究或者应用者大大加分

【薪资 & HeadCount】

薪资范围：15k - 30k

本次招聘 2 位 React Native 前端工程师

与我联系

[绍兴柯桥 / 杭州萧山] 有数派诚聘 Ruby 后端工程师 / 长期有效 ( 15K - 32K )

cn_boris — Mon, 27 May 2019 20:04:05 +0800

什么是有数派？

有数派 ( https://youshupai.com ) 是

目前产品功能覆盖了交易、⽣产、质检、仓储、工业控制 ( 物联网 ) 等业务场景，终端覆盖了 TV、手机、PC、iPad、PDA 等设备，我们通过 SaaS 工具提升纺织企业交易/运营效率，同时通过实时数据监控、数据可视化、数据分析和数据追溯协助企业做业务决策，用数据驱动业务增长。

系统目前管理了⼏十亿的⾯料交易订单与几亿匹的布匹数据。UGG、Zara、海澜之家、七匹狼、Tommy、CK 等几十家知名服装厂商的面料供应商都在使用我们的产品。

相关媒体报道：

自主研发了技术架构 + 设计模式，有数派要帮助纺织企业更好地进行管理与运营 - [自主研发了技术架构+设计模式，有数派要帮助纺织企业更好地进行管理与运营](https://www.lieyunwang.com/archives/446073)
当互联网嵌入传统纺织业，有数派想以 SaaS 工具切入 B2B 交易 - [当互联网嵌入传统纺织业，有数派想以SaaS工具切入B2B交易](https://36kr.com/p/5148992)

我们的工程师团队：

目前我们的研发团队一共有 20 多位同事

前端（React Native + React + iOS & Android）10 位

后端（纯后端 Ruby）7 位

产品 & 设计若干

我们来自：

我们的技术栈：

全套 GraphQL + Ruby on rails + PG + React + React Native + MQTT（IoT） .

我们可能是国内为数不多在后端架构上全套使用 GraphQL 技术的公司，目前用 GraphQL 支撑了 6 个客户端的业务覆盖了近 200 个 Model。

团队撰写了国内第一本 GraphQL 中文书籍（即将出版） & GraphQL 布道者

杭州第一届 GraphQLParty - [杭州第一届 GraphQLParty](http://www.huodongxing.com/event/7441170737900?from=groupmessage)

我们在找什么样的人

【基础要求】

0、相信产业互联网的机会，并愿意投身传统行业改造浪潮的工程师

1、3 年以上 Ruby on Rails 开发经验；

2、具有扎实的语言基础，良好的面向对象编程思想；

3、掌握常用的设计模式，了解移动互联网相关技术；

4、熟悉 Linux 类环境，能熟练使用 Unix 类系统下的 ruby 编程；

5、熟悉 MYSQL、PG 或其他大型数据库，能够快速根据需求完成高性能数据库设计，有大负载高可靠设计经验；

【加分项】

1、有 Iot 工业产品或大规模数据应用开发经验者加分

2、对前端技术有一定的应用者大大加分（React 方向）

3、对 GraphQL 技术栈有一定的研究或者应用者大大加分

【薪资 & HeadCount】

薪资范围：15k - 30k

本次招聘 3 位后端工程师

与我联系

[绍兴柯桥 / 杭州萧山] 有数派诚聘 Ruby 后端工程师 / 长期有效 ( 15K - 30K )

cn_boris — Mon, 08 Apr 2019 14:48:24 +0800

什么是有数派？

有数派 ( https://youshupai.com ) 是

相关媒体报道：

自主研发了技术架构 + 设计模式，有数派要帮助纺织企业更好地进行管理与运营 - [自主研发了技术架构+设计模式，有数派要帮助纺织企业更好地进行管理与运营](https://www.lieyunwang.com/archives/446073)
当互联网嵌入传统纺织业，有数派想以 SaaS 工具切入 B2B 交易 - [当互联网嵌入传统纺织业，有数派想以SaaS工具切入B2B交易](https://36kr.com/p/5148992)

我们的工程师团队：

目前我们的研发团队一共有 20 多位同事

前端（React Native + React + iOS & Android）10 位

后端（纯后端 Ruby）7 位

产品 & 设计若干

我们来自：

我们的技术栈：

全套 GraphQL + Ruby on rails + PG + React + React Native + MQTT（IoT） .

我们可能是国内为数不多在后端架构上全套使用 GraphQL 技术的公司，目前用 GraphQL 支撑了 6 个客户端的业务覆盖了近 200 个 Model。

团队撰写了国内第一本 GraphQL 中文书籍（即将出版） & GraphQL 布道者

杭州第一届 GraphQLParty - [杭州第一届 GraphQLParty](http://www.huodongxing.com/event/7441170737900?from=groupmessage)

我们在找什么样的人

【基础要求】

0、相信产业互联网的机会，并愿意投身传统行业改造浪潮的工程师

1、3 年以上 Ruby on Rails 开发经验；

2、具有扎实的语言基础，良好的面向对象编程思想；

3、掌握常用的设计模式，了解移动互联网相关技术；

4、熟悉 Linux 类环境，能熟练使用 Unix 类系统下的 ruby 编程；

5、熟悉 MYSQL、PG 或其他大型数据库，能够快速根据需求完成高性能数据库设计，有大负载高可靠设计经验；

【加分项】

1、有 Iot 工业产品或大规模数据应用开发经验者加分

2、对前端技术有一定的应用者大大加分（React 方向）

3、对 GraphQL 技术栈有一定的研究或者应用者大大加分

【薪资 & HeadCount】

薪资范围：15k - 30k

本次招聘 3 位后端工程师

与我联系

[上海] 红杉资本招聘数据开发& web 全栈实习生

cn_boris — Tue, 13 Mar 2018 15:27:17 +0800

我们是谁

红杉资本始终致力于帮助创业者成就基业常青的伟大公司，为成员企业带来丰富的全球资源和宝贵的历史经验。45 年来，红杉资本投资了众多创新企业，包括苹果、思科、甲骨文、谷歌、阿里巴巴、Airbnb、京东等产业潮流领导者。

红杉资本在中国、印度、美国三个全球最具创新力或发展潜力的国家设有本地化基金。

红杉资本中国基金作为「创业者背后的创业者」，专注于科技/传媒、医疗健康、消费品/服务、工业科技四个方向的投资机遇。十二年来，红杉资本中国基金投资了包括阿里巴巴、阿里影业、贝达药业、铂涛酒店集团、大众点评网、德邦物流、DJI 大疆创新、赶集网、高德软件、光环新网、华大基因、今日头条、京东、聚美优品、美丽说、美团网、陌陌、诺亚财富、奇虎 360、万达院线、威高集团、唯品会、文思创新、新产业生物、新浪网、英雄互娱、鱼跃医疗、掌趣科技、中通快递在内的 300 余家企业。

工作地点

上海市静安区恒隆广场

工作内容

与合作方对接 API 接口，进行各类外部数据源的接入与维护；
分布式爬虫的开发与维护、数据的清洗与加工；
参与 BI 系统的 web 开发；
参与自然语言处理和数据挖掘。

能力要求

能熟练使用 Python、Ruby、Go、Scala、Grovvy、Java 语言中的一种或多种（Ruby 优先），熟悉 SQL 语言和常用 Linux 命令；
熟悉常用的数据结构，对分类算法、聚类分析、回归模型等有基本了解；
基本掌握 React、VUE、Angular等前端开发框架的一种或多种，有 web 开发经验；
在爬虫、反爬虫、ETL、数据仓库、数据可视化方面拥有实际工作经验者优先；
曾在信息学奥赛、ACM 竞赛中获奖者优先;
参与过开源项目，github star 数量多者优先;
了解右列技术中一种或多种者优先： functional programming、 Spark、Elasticsearch、Neo4j、GraphQL、Docker、Serverless。

简历请投 echo aHJpbnRlcm5Ac2VxdW9pYWNhcC5jb20K | base64 -D (标题注明 ruby-china 有加分)

[北京] 15-30K 逐鹿 X 招聘 Ruby/ 全栈工程师资深前端工程师

cn_boris — Wed, 27 Jan 2016 21:18:05 +0800

为什么是我们

我们通过知识、经验和思考改变世界，而不是——「我有一个改变世界的 idea，只差一个程序员了」。
高于 BAT 的顶尖薪资 / 五险一金及商业补充保险 / 餐费及话费补助
站在硅谷与华尔街的十字入口，你的工作将极大的提高整个行业的投融资效率从而让这个世界变得更加美好。换言之，这份工作能让你真真切切的走在改变世界的路上。
完善的技术成长体系，我们与知名技术服务平台——极牛合作，每月邀请业界大牛进行技术交流 （目前已组织了和豆瓣前端负责人张克军、美团 iOS 负责人陈晓亮等业内大牛的交流活动），同时我们也是 Rubyconf China 2015 的银牌赞助商。

招聘岗位

资深前端工程师（15-30K）

岗位职责：

负责 Hybrid App 的开发工作
负责前端团队工具链的选型及持续优化

任职要求：

拥有丰富的前端工程经验，特别是 Hybird App 开发经验，熟悉 Cordova 相关 API 接口；
深刻理解 web 标准，对前端性能、可访问性、可维护性等知识拥有实践经验；
熟悉 webpack 或其他前端工具链，对于提升前端团队开发效率有自己的独道见解；
熟悉至少一门非前端脚本语言；
在 Github 上有开源项目；
了解 iOS 或 Android 原生应用开发者优先考虑。

Ruby/全栈工程师（15-30K）

岗位职责：

负责业务支撑系统的研发及 DevOps

任职要求：

拥有 2 年以上 Ruby on Rails 项目经验；
如果应聘全栈工程师熟悉至少一种前端 MVC 框架，包括但不限于 AngularJS、React、Vue.js；
熟悉 PostgreSQL 数据库或有 OLAP 系统开发经验者优先。

我们是谁

逐鹿 X 是一款以创业者需求为核心的投融资工具。我们期望通过技术的力量，为尚处于刀耕火种时代的创投领域带来文明之光。 http://e.vhall.com/874122178

如何勾搭

请 Email 简历至 hr[at]zhulux.com

同时务请附上您的 Github 帐号或技术博客地址这将作为我们研判的重要依据

使用 Nginx 解決 Google Analytics 在大陆被牆的問題

cn_boris — Sat, 19 Sep 2015 05:35:41 +0800

需求點

由於眾所周之的原因，Google Analytics 在大陸地區總是「不太穩定」，且無其他可真正比肩者。故而需要通過海外服務器作為反向代理以解決此種問題。同時為統計結果之準確計，必須確保用戶 IP 等信息得以透明傳輸。

解決方案

nginx 配置文件：

server {
    listen 80;
    listen 443 ssl spdy;
  server_name analytics.example.com;      
    ssl_certificate /usr/local/tengine/certs/example.crt;
  ssl_certificate_key /usr/local/tengine/certs/example.key; 
  location /ga_proxy {
    proxy_set_header            X-real-ip $remote_addr;
    rewrite ^/ga_proxy/(.*)$ /$1?$args&uip=$remote_addr;
    proxy_pass http://www.google-analytics.com;
    break;
  }
  location /analytics.js {
    default_type text/html;
    subs_filter_types text/css text/xml text/javascript;
    subs_filter 'www.google-analytics.com' 'analytics.example.com/ga_proxy' g;
    proxy_set_header            X-real-ip $remote_addr; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Referer https://www.google-analytics.com;
    proxy_set_header Host www.google-analytics.com;
    proxy_pass https://www.google-analytics.com;
    proxy_set_header Accept-Encoding "";
  }
}

客戶端 JS 代碼：

(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//analytics.example.com/analytics.js','ga');
ga('create', 'UA-EXAMPLE-0', 'auto');
ga('send', 'pageview');

原文首發於我的博客 https://hacker.design/ji-yu-nginxfan-xiang-dai-li-jie-jue-google/

複雜邏輯下解耦 CANCANCAN 的 Ability 模型

cn_boris — Sat, 19 Sep 2015 05:32:44 +0800

業務場景

假定系統中存在 developer hacker designer startup 四種角色，且每種角色具獨立的權限需求。倘全部定義於ability.rb則未免過於臃腫而不可讀。

解決方案

基於角色維度進行ability.rb的切分如下：

# app/models/ability.rb
class Ability
  include CanCan::Ability

  def initialize(user)
    user ||= User.new
    if user.id.present?
      self.merge Abilities::LoginedUserAbility.new(user)
      self.merge Abilities.const_get("#{user.role}_ability".classify).new(user) if user.role.present?
    else
      self.merge Abilities::GuestAbility.new
    end
  end

end

# app/models/abilities/logined_user_ability.rb
module Abilities
  class LoginedUserAbility
    include CanCan::Ability
    def initialize(user)
     # ...
    end
  end
end

# app/models/abilities/developer_ability.rb
module Abilities
  class DeveloperAbility
    include CanCan::Ability
    def initialize(user)
     # ...
    end
  end
end

其餘角色同上

原文首發於我的博客 https://blog.boris.tech/posts/fu-za-luo-ji-xia-jie-ou-cancancan-de-ability-mo-xing

[北京] 10-40K 诚聘 Ruby 开发者及 NLP 工程师投行内部创业项目

cn_boris — Mon, 24 Aug 2015 20:24:02 +0800

我们是谁

华兴资本是国内 TMT 领域最顶尖的投资银行（没有之一），亦是 滴滴快滴合并、京东&微博&陌陌上市、 豌豆荚&饿了吗融资 等等一系列互联网圈大案要案的「幕后推手」。

逐鹿 X 是华兴资本旗下的一个内部创业项目。我们期望通过技术的力量，为尚处于刀耕火种时代的创投领域带来文明之光。

我们的主要技术栈是：Ruby on Rails、PostgreSQL、Redis、AngularJS & Ionic、RSpec & Karma、Sass&CoffeeScript，以及我们在团队内部实践 TDD、Scrum 和 DevOps。

为什么是我们

我们提供最卓越的薪酬福利及工作环境。包括但不限于：高于 BAT的顶尖薪资、补充商业保险、每年至少15 天年假、（已经成为互联网公司标配的）人体工学座椅、顶配 MBP、大屏显示器、无限量零食供应。
作为大型企业的内部创业项目，尽管我们从零开始但拥有最丰富的资源和行业经验。
我们真的在改变世界。我们真的在改变世界。我们真的在改变世界（重要的事情一定要说三遍）。你的每一行代码，都旨在让整个真实世界的创业融资更有效率、将数以万计的人们从繁琐机械的重复劳动中解救出来，并基于此让整个世界变得更加美好。
我们是一支由心怀壮志的专业人士组成的团队——每个人都在自己的专业领域具备丰富经验及独到见解。我们通过知识、经验和思考改变世界，而不是——「我有一个改变世界的 idea，只差一个程序员了」。

招聘岗位

Ruby Developer (10-30k)

任职要求：

熟悉 Ruby on Rails。
熟悉右列语言中的任意 1 种（ECMAScript、Python、Swift、Go、Erlang、PHP）。
使用*nix 系统作为开发及生产环境。
熟悉至少一种关系型或非关系型数据库。
了解 RESTful 规范，并有相关之实践经验。
了解 SQL Injection、XSS、CSRF 等常见 web 攻击手段及其防御方法。
基本了解 TDD、Scrum 及 DevOps 理念。

加分项：

具 haskell、lisp 等函数式编程语言使用经验。
具 Docker 或 Puppet 经验。
了解 Growth Hacker。

NLP 自然语言处理工程师（10-40k）

任职要求：

熟悉至少一种脚本语言。
拥有扎实的数理基础，对数据结构拥有较深入之了解。
熟悉进行文本数据挖掘所必须的各项手段，包括但不限于：中文分词、情感分析、自动摘要。
对基于协同过滤的推荐算法具有一定的了解及实践经验。
对算法复杂度及算法优化具有较为敏锐之感知。

加分项：

在高影响因子的期刊或会议上发布过相关领域论文。
具有 haskell、lisp 等函数式编程语言使用经验，或具有 GPU 编程经验。
具有 Deep Learning、Knowledge Graph 等方向之实践经验。
具有非结构数据的数据挖掘经验。

如何勾搭

请将您的简历 Email 至 borisding【at】huaxing.com（PDF 格式）。如若能够随手附上 Github、Dribbble、StackOver、Ruby China、SegmentFault 或其他在线社区 ID，将帮助我们更深入的了解您。

Here's To The Crazy Ones. The misfits. The rebels. The trouble-makers. The round pegs in the square holes. The ones who see things differently. They're not fond of rules, and they have no respect for the status-quo. You can quote them, disagree with them, glorify, or vilify them. About the only thing you can't do is ignore them. Because they change things. They push the human race forward. And while some may see them as the crazy ones, we see genius.

Rails4 + Carrierwave 下實現 JSON 形式的文件上傳 API

cn_boris — Sat, 15 Aug 2015 12:23:52 +0800

相較於傳統的 multipart/form-data 表單上傳，在 API 中將文件以 Base64 形式編碼後置於 JSON 中會是更為妥貼的實現方式。

Carrierwave 是一個知名的文件上傳 GEM。下文將主要闡述在 Rails4 與 Carrierwave 中如何實現一個不依賴於具體數據庫的獨立上傳 API。

# app/models/media.rb

class Media  
  include ActiveModel::Model

  attr_accessor :path, :type, :original_filename, :content_type
  attr_writer :file
  validates :path, presence: true
  validates :original_filename, presence: true
  validates :content_type, presence: true
  validates :type, inclusion: %w(logo image video)

  def file
    data = StringIO.new(Base64.decode64(@file))
    data.class.class_eval { attr_accessor :original_filename, :content_type } # 確保與 Carrierwave 所預期的格式保持一致
    data.original_filename = original_filename
    data.content_type = content_type
    data # 返回 data
  end

  def upload!
    uploader = Object.const_get("#{type.classify}Uploader").new # 允許按需上傳到不同的 Uploader
    uploader.store! file
    self.path = uploader.url
  end

end

為保證更好的閱讀體驗，全文請見我的博客： https://hacker.design/design-json-upload-api-base-by-carrierwave/

[北京国贸] 招聘全栈或 Ruby 开发者华兴资本旗下内部创业项目

cn_boris — Sun, 19 Jul 2015 23:16:14 +0800

我们是谁

逐鹿 X 是华兴资本旗下的一个内部创业项目。我们期望通过技术的力量，为尚处于刀耕火种时代的创投领域带来文明之光。

招聘岗位

Web Developer (全栈/前端/ruby)

你将参与到后端 RESTful API 及前端 SPA 的开发（可以只参与到其中一种，亦可兼而有之。重点是你开心就好^_^）

我们的主要技术栈是：Ruby on Rails、PostgreSQL、Redis、AngularJS & Ionic、RSpec & Karma、Sass&CoffeeScript。

我们对于全栈的定义并不局限于技术领域。我们更期望你目前是或想要成为一名 Growth Hacker (https://en.wikipedia.org/wiki/Growth_hacking) 。

以及我们在团队内部实践 TDD、Scrum 和 DevOps。

在面试过程中，我们会重点关注你之前做过的项目、踩过坑与总结的经验以及对技术的展望。

为什么是我们

我们提供最卓越的薪酬福利及工作环境。包括但不限于：高于 BAT的顶尖薪资、补充商业保险、每年至少15 天年假、（已经成为互联网公司标配的）人体工学座椅、顶配 MBP、大屏显示器、无限量零食供应。
作为大型企业的内部创业项目，尽管我们从零开始但拥有最丰富的资源和行业经验。
我们真的在改变世界。我们真的在改变世界。我们真的在改变世界（重要的事情一定要说三遍）。你的每一行代码，都旨在让整个真实世界的创业融资更有效率、将数以万计的人们从繁琐机械的重复劳动中解救出来，并基于此让整个世界变得更加美好。
我们是一支由心怀壮志的专业人士组成的团队——每个人都在自己的专业领域具备丰富经验及独到见解。我们通过知识、经验和思考改变世界，而不是——「我有一个改变世界的 idea，只差一个程序员了」。

如何勾搭

Here's To The Crazy Ones. The misfits. The rebels. The trouble-makers. The round pegs in the square holes. The ones who see things differently. They're not fond of rules, and they have no respect for the status-quo. You can quote them, disagree with them, glorify, or vilify them. About the only thing you can't do is ignore them. Because they change things. They push the human race forward. And while some may see them as the crazy ones, we see genius.

一个测试 JSON API 时用来对比 JSON 内容的 helper，以及请教是否有更优雅的写法

cn_boris — Tue, 21 Apr 2015 17:43:09 +0800

业务需求

在测试 json api 时，测试返回的 json 是否与预期的一致。

最初的解决方案

使用了一个叫做 assert_json 的 GEM。但感觉过于繁琐，特别是在测试用例多的时候。

现时的解决方案

手写了几个 helper

def response_json
   JSON.parse(response.body)
 end

 # data_map could look like {uid: :id,last_name: :last_name,full_name: '"#{exp['last_name']}#{exp['first_name']}"'}
 def assert_json_equal(exp, data_map=nil, act=response_json)
   act=JSON.parse(act) if act.is_a?(String)
   data_map || (data_map=act.keys)
   (data_map = Hash[data_map.map { |v| [v, v.to_sym] }]) if data_map.is_a?(Array) # convert array to hash (key == value)
   data_map.each do |k, v|
     k=k.to_s
     if v.is_a?(Symbol)
       assert_equal exp[v], act[k]
     elsif v.is_a?(String)
       assert_equal eval(v), act[k]
     elsif v.is_a?(Hash) # support insets
       assert_json_equal(exp,v,act[k])
     else
       false
     end
   end
 end

使用示例

假设我们有这样 1 个 model

User (id,last_name,first_name,password,updated_at,created_at)

当 json 返回值为 User.first.to_json 时，直接使用 assert_json_equal User.first 即可，而无需指定 data_map。

当 json 只返回 {"id":1,"last_name":'Jobs'} 时，则需使用数组作为 data_map，形如 assert_json_equal User.first,[:id,:last_name]

而当 json 返回的数据结果较复杂时，则需要使用 hash 作为 data_map，形如：

 // json 返回结果
{"uid":1,full_name: 'Steve Jobs',password:'123'}

# 验证json返回
@data_map={
  uid: :id,
  full_name: '"#{exp.first_name} #{exp.last_name}"',
  password: :password
}

 assert_json_equal User.first,@data_map

问题

总觉得这样的实现似乎有点怪怪的，以及是否有更优雅的写法？

Ruby 新手一枚，还望各位大牛不吝赐教。

如何权衡 DRY 与可读性

cn_boris — Wed, 24 Dec 2014 16:34:37 +0800

*** UPDATE ***

抱歉之前精简了部分无关的业务代码，可能导致了一定的误导性。现在补上完整的应用场景

比如同一功能的下述两种实现方式，大家觉得使用那种会更恰当？

# 方案1

module ApiHelper
  %w(get post put patch delete).each do |method|
    module_eval(<<-EOF, __FILE__, __LINE__)
      def api_#{method}(params={},headers={}}
        headers.merge!('X-Token' => CFG['api_token']['apollo'])
        #{method}(path,params,headers)
      end
    EOF
  end
end

# 方案 2

module ApiHelper
  def api_get(params={},headers={})
  request_send :get,params,headers
  end

  def api_post(params={},headers={})
  request_send :post,params,headers
  end

  def api_put(params={},headers={})
  request_send :put,params,headers
  end

  def api_patch(params={},headers={})
  request_send :patch,params,headers
  end

  def api_delete(params={},headers={})
  request_send :delete,params,headers
  end

  private

  def request_send(method,params={},headers={})
    headers.merge!('X-Token' => CFG['api_token']['apollo'])
    send method,params,headers
  end
end

Announcing RemoteIE: Test the latest IE on Mac OS X

cn_boris — Tue, 04 Nov 2014 11:49:33 +0800

Today, we’re excited to announce the preview availability of RemoteIE via Azure RemoteApp.

This is a free service from Microsoft that allows you to run the latest version of Internet Explorer on the Windows 10 Technical Preview from your Windows, Mac OS X, iOS or Android devices, without the need to run a new OS or heavyweight virtual machine on your device.

Going forward, this will be the recommended way for developers who are not running Windows 10 to test the latest IE preview versions.

http://blogs.msdn.com/b/ie/archive/2014/11/02/announcing-remoteie-test-the-latest-ie-on-windows-mac-os-x-ios-and-android.aspx

[广州] 情感行业互联网创业公司诚聘 Ruby 研发工程师（Senior/ 实习 / 应届皆宜）

cn_boris — Wed, 10 Sep 2014 18:05:32 +0800

关于公司

泡学网（ www.paoxue.com ）成立于 2008 年 3 月是目前国内最大的男性情感门户。

迄今为止，我们已经成功帮助超过 50 万会员提升约会、恋爱、社交等技能。

网站拥有原创文章超过 350 万，包含内容丰富的约会、恋爱、社交资讯。

欢迎点击这里查看我们的简介视频

关于团队

作为互联网公司，我们热衷于把玩 Ruby、ODPS（阿里云版 hadoop）、响应式设计、Scrum 管理等业界最为前沿的技术；

作为创业公司，我们没有各种笑里藏刀的「办公室政治」或者臃肿不堪的「办事流程」；

作为情感行业的公司，我们能够为你提供系统的培训机会，以便你能够在人际关系领域得到极大的成长（确实，某种程度上这意味着你得到了一本《恋爱秘籍》，只要你愿意相信情感是一门可以被习得的艺术）。

基本要求

熟悉我们的技术栈（Linux + ROR + MySQL + Memcached + Nginx + Git）；

真正热爱服务器端编程，而不仅仅将 coding 作为一种谋生工具；

加分项

熟悉 JRuby；

有自己的技术博客或在 Github 中参与多个开源项目;

把玩过 PHP 或 JAVA;

关于薪资

我们将根据能力确定薪资，总体而言高于业界平均水平且上不封顶。

其他

如有意向烦请将简历 email 至 hr[at]pv.cc 。作为技术岗位的招聘，请务必在 email 中附上你的 Github 地址。如果可能，烦请尽量使用 PDF 格式投递简历。

在面试过程中，我们会重点关注你之前做过的项目、踩过坑以及总结的经验。

[广州] 靠谱互联网团队招人

cn_boris — Wed, 16 Jul 2014 22:03:01 +0800

我们是一家立足于情感行业的互联网创业公司，坐标广州大学城。

作为互联网公司，我们热衷于把玩 Ruby、ODPS（阿里云版 hadoop）、响应式设计、Scrum 管理等业界最为前沿的技术；作为创业公司，我们没有各种笑里藏刀的「办公室政治」或者臃肿不堪的「办事流程」；作为情感行业的公司，我们能够为你提供系统的培训机会，以便你能够在人际关系领域得到极大的成长（确实，某种程度上这意味着你得到了一本《恋爱秘籍》，只要你愿意相信情感是一门可以被习得的艺术）。

以下是正在招聘的岗位清单，如有意向烦请将简历 email 至 hr[at]pv.cc 。作为技术岗位的招聘，请务必在 email 中附上你的 Github 地址。如果可能，烦请尽量使用 PDF 格式投递简历。

Web 研发工程师（Senior 级）

我们主要使用 Ruby 来进行后端开发，偶尔也会基于业务需求混搭些 PHP、JAVA 神马的。当然，我们并不要求你同时具有上述几种语言的项目经验。因为，我们相信具有 Senior 级经验的你完全可以在相对短的时间里基本掌握一门新的语言。

尽管我们有专职的前端工程师，但你可能偶尔也需要写一些简单的页面。对了，我们使用 Bitbucket 进行代码管理。所以，你必须要能够熟练的使用 Git 以及 Bootstrap。

尽管我们不要求强制实施 TDD，但大多数情况下你可能被要求给自己的代码加上单元测试。

在面试过程中，我们会重点关注你之前做过的项目、踩过坑以及总结的经验。

Web 研发工程师（实习&应届）

理想情况下，我们期望你已经做过至少 2 个实现了完整功能的网站项目、了解诸如 MVC、ORM、设计模式、数据结构之类的基本概念。

同样，作为加入团队的最低要求你必须已经能够熟练的使用 Git 以及 Bootstrap。

具有足够优秀的自学能力，也是你胜任这一岗位的基本要求。

在面试过程中，我们将重点考察你的学习能力、沟通能力以及诸如算法、数据结构之类的基本功。

前端开发工程师（Senior 级）

理想情况下，我们期望你已经具有多年的前端开发经验。无论高端大气上档次的 ECMAScript 或者坑爹苦逼超屌丝的 IE6 兼容，对你而言都是小菜一碟。（当然，作为一家有节操的互联网公司实际上我们只要求兼容 IE8 及以上版本）

作为 Senior 级别的 F2E，你将主要负责前端框架的维护以及前端组件的开发。我们使用支付宝前端团队的 Sea.js、Arale 以及 Alice ui 作为前端解决方案，如果你有这方面的经验便是再好不过了。

要是你有使用 LESS/SASS 或者 CoffeeScript 的经验，那会成为占有极高权重的加分项。

在面试过程中，我们将重点考察你的基本功底（JS&CSS）以及架构规划能力。

测试工程师（实习&应届）

你将主要负责各个项目的集成测试工作。所以，你必须要心细如丝到令人发指以至于走火入魔的境界。（摁，某种意义上这意味着你可能要有类似于处女座的那种性格。）

我们在尽可能的实行测试自动化，以帮助你摆脱那些枯燥且繁复的「脏活」。所以，你必须要具有足够牛逼的学习能力以及基本的脚本语言编程功底以驾驭那些自动化工具。

当然，受限于工具的局限性。偶尔你可能还不得不去人肉完成那些枯燥且繁复的「脏活」，所以你必须要有足够的耐心才能够胜任这一工作。

你也会负责整理一些基本的技术文档，所以你必须具有流畅且无歧义的文字表达能力。

在面试过程中，我们将重点考察你的学习能力、程序语言基础（C、Java、pascal 或你学过的其他语言）以及语言表达能力。

cn_boris (Boris Ding)

[远程或宁波] 30-60K Brickdoc 招聘软件开发工程师

我们是谁

我们怎么做事

我们的技术栈

我们在找怎样的人

软件开发工程师（前端或全栈）

软件开发工程师（后端或全栈）

如何联系我们

Shopify 的 GraphQL API 设计指南

教程：GraphQL API 的准则

目录

简介

步骤 0: 假定背景

步骤 1: 全局概览

步骤 2: 少既是多

避免暴露 CollectionMembership 表

重新思考合集

结论

步骤 3: 增加细节

最初实现

ID 和 Node 接口

Rules 字段和子对象

列表和分页

字符串

关联对象的 ID

命名与标量（Scalar）

分页的再思考

枚举（Enum）

步骤 4: 商业逻辑

步骤 5: 变更（Mutation）

根据具体业务来划分支持的操作种类

思考对象与对象间的关系

Input: 结构 - 第一部分

Input: 标量

Input: 结构 - 第二部分

Mutation 的返回值

TLDR: 设计准则总结

结尾

null

[绍兴柯桥 / 杭州萧山] 有数派 诚聘 Ruby 后端、React、React Native 前端工程师 / 长期有效 ( 15K - 30K )

什么是有数派？

融资情况？

我们的工程师团队：

我们的技术栈：

我们在找什么样的人

Ruby 工程师

React 工程师

React Native 工程师

与我联系

[北京][实习] Oortcast 招聘 SDE Intern

技能要求

岗位收益

工作地点

与我们联系

我们是谁

我们的价值观

科技向善的市井雄心

绝不重复你自己

人人都是斜杠青年

[绍兴柯桥 / 杭州萧山] 有数派 诚聘 Ruby 后端、React、React Native 前端工程师 / 长期有效 ( 15K - 30K )

什么是有数派？

融资情况？

我们的工程师团队：

我们的技术栈：

我们在找什么样的人

Ruby 工程师

React 工程师

React Native 工程师

与我联系

[绍兴柯桥 / 杭州萧山] 有数派 诚聘 Ruby 后端工程师 / 长期有效 ( 15K - 32K )

什么是有数派？

我们的工程师团队：

我们的技术栈：

我们在找什么样的人

与我联系

[绍兴柯桥 / 杭州萧山] 有数派 诚聘 Ruby 后端工程师 / 长期有效 ( 15K - 30K )

什么是有数派？

我们的工程师团队：

我们的技术栈：

避免暴露 `CollectionMembership` 表

ID 和 `Node` 接口

`Rules` 字段和子对象

[绍兴柯桥 / 杭州萧山] 有数派诚聘 Ruby 后端、React、React Native 前端工程师 / 长期有效 ( 15K - 30K )

[绍兴柯桥 / 杭州萧山] 有数派诚聘 Ruby 后端、React、React Native 前端工程师 / 长期有效 ( 15K - 30K )

[绍兴柯桥 / 杭州萧山] 有数派诚聘 Ruby 后端工程师 / 长期有效 ( 15K - 32K )

[绍兴柯桥 / 杭州萧山] 有数派诚聘 Ruby 后端工程师 / 长期有效 ( 15K - 30K )

[北京] 15-30K 逐鹿 X 招聘 Ruby/ 全栈工程师资深前端工程师

[北京] 10-40K 诚聘 Ruby 开发者及 NLP 工程师投行内部创业项目

[北京国贸] 招聘全栈或 Ruby 开发者华兴资本旗下内部创业项目

[广州] 情感行业互联网创业公司诚聘 Ruby 研发工程师（Senior/ 实习 / 应届皆宜）