主力用的 5 位的，唯一的麻烦是每两三天至少有一个好友请求问 Q 号卖不卖的。

永远都是后端计算就好了啊，前端直接调用后端的接口取结果啊，两个地方计算一来是前端的计算永远不可信，二来是后期维护也麻烦啊。

这种发布会，多路视频通过导播台直接切换哪路信号就好了吧。

公司这么做，对你一点限制都没有。
正确的做法是，签劳动合同时上面要有相关条款，离职时要有协议，表明在多长期限内，每月给多少钱，这个钱的标准各地不一，从过去 12 个月平均收入的 20%到 50%。

唯一楼主要注意的是，如果创业和原来的项目一样，尤其是技术类的，小心点不要用原公司专有的技术。

倒是不错啊，可惜近一两个月时间都基本满了。
顺带问一下， C#主要做哪个方面的开发？

这个是国际版的，国内版会支持么？

同 ip6 用户，连阿婆表 1 代，索大 1000x ， Jebra 运动耳机没有问题。

看情况吧，某些极端情况下，为了灵活调整，在数据库里建一个专门的对应表也可以吧。
以性别为例（当然这个不是特别极端，所以不是很合适，看看意思就好），比如建个性别表，有 id ，有描述，里面可以随时添加，比如：男，女，不男不女，变性，保密。。。。。。
用户表就存性别 id 就好了，传给前端的用户数据可以有 id ，也可以附带一项比如 gender_desc 把对应的描述加上啊。

有期望的工作内容和薪资范围么？

@jarlyyn 我觉得问题是微信授权后要做什么吧，比如至少基本授权拿到用户的 open-id ？那样的话拿到 code 后需要 appid 和 appkey 去取用户的 open-id ？这一步如果在前端做的话，是要把 appkey 也写到前端去么？这部分就是我一直没想明白的。

@halden angular 1 出来得太早，好多现在的标准都没有所以比较惨。 2 的话可以充分利用现代新标准了，所以有些比较大的变动出现在 1 和 2 之间我觉得是可以理解的吧。

我的 5 位靓号应该差不多 15 年了，去年买了四年超级会员买断的。还有两个 6 位的还好不是靓号。

@noli 大家说得没错啊， RESTFul 不是协议，也不是规范，只不过是诸多 WEB API 设计架构中被比较多人说得比较多的一种而已。
没人规定说 WEB API 一定要按 REST 来设计，事实上能看到的很多 API 要么并不按 REST 来做，要么并没有严格按照 REST 来做。

总结一下，上面说的那么些，我想表达的是 REST 只不过是一种架构，做 WEB API 时不需要一定要跟着他，同样大家在这里讨论 WEB API 的时候，也不需要拿他来说什么。

那么说回用 HTTP 状态码，还是单独返回一个状态码？这个我估计 V2 上可能都争论过很多次，支持的双方都有吧。
从我个人来说，我更喜欢单独返回一个状态码，用来把业务逻辑的状态，和非业务逻辑的状态区分开来。

再总结一下，后面说得这么些，我想表达的这两种做法没有绝对的对错，没有必要因为别人和自己的选择不同而喷对方。这个选择应该是公司来做，如果公司没做好，喷的是公司。

以前交行 Master 可以，现在已经不行了。

97.5 ，没变化，维持 23500 ，就是另外给了 500 临时额度………………

@liangduoduo 大家说的前后端分离，就是后端统一返回 json ， web 前端由 javascript 在客户浏览器端根据 json 得到的数据来渲染生成页面