@binux 哦，我明白了，你根本没见过几个HR，你只是偏见。

@binux

难道还要让 新公司的HR 把期权给你算出等额工资？？？

HR会说， 期权就像买彩票，公司成功了，钱才是你的，所以新公司的薪资不能把彩票也算进去

@ymy89757

个人水平？

如果你和别人去创业，拿着5K薪水干了两年，最后不行了， 要去找新工作。

新工作的薪水不以 技术水平 和 新公司薪酬体系 来评估

以5K 来评估？

我一向诚实说明我的工资情况

上次去面一家公司，总之弄了几小时都搞定了，
HR最后和我谈薪资，问了我期望薪资和目前薪资
然后HR说可能有点难，因为工资涨幅超过20% 是很难通过的。

然后我说那我就不考虑了。

之后HR来了两次电话，让我考虑，我直接回绝了。


根据上一家的薪资，来定新工作的薪资，反正我不爽

我只想说， 出钱让学习， 没有比这么更好的事情了

我学过 basic, c, c++, c#, erlang, hashell, java, javascript, lua, ocmal, python, php, rust,

写起来最舒服（即流畅，又严谨）的是C#
如果 微软原生的.net 能够跨平台的话， 我相信肯定有用 Linux + C# 做服务器的。

理解LZ， 我学的时候 就是一个 test project

自动生成的文件是 Program.cs
内容大概是

using System;
using System.Collections.Generic;


namespace test
{
class Program
{
....public static void Main (string[] args)
....{
........ //
....}
}
}

然后 我自己去建立一个class ，生成一个文件， TestA.cs

在里面写个 方法，

同样的，建立其他class， 在生成的对应文件里 写 功能。


最后 就在 Program.Main 方法中 去调用这些 功能就行。




这样就可以做到一个 project， 做多个练习的目的

@reorx

你说的对， JSON 和 protobuf 肯定是要用在各自合适的环境中

比如我的项目：

服务器 ， 客户端之间是 protobuf
服务器各个组件之间的API调用 是 json

我之所以有那个对比的测试， 是想测试一下 在 服务端和客户端用 gzip 压缩的json，看到底是否可行。
从结果来看，erlang/python服务端基本没影响， c#客户端性能降低了好多。
结论就是 如果是 弱交互，消息通信不频繁的项目， 直接上json就行。不过最好gzip压缩一下


至于你后来说的， **一旦定义过的required字段，不允许更改** 这个我不赞同

有些功能一改再改，到最后直接换个方式玩法， 消息大概是必然的。

所以这才是版本控制的重要性。

@dcoder

用 precompile 来应对 IOS 的 AOT 问题
我是参考的这个帖子： http://game.ceeger.com/forum/read.php?tid=13479

我直接写一个 命令行工具来做这些事情： https://github.com/yueyoum/pg

@dcoder
protobuf-net 在IOS确实有 AOT的问题， 我在 github中的说明里 特别提过了，以及解决办法。

估计是 那篇说明太长， 大部分都没仔细看。

就像上面还有些同学总说 web 什么的， 显然我不是做web的啊。


关于 Layers， 我的感觉是 Layers 肯定是不会少的，

毕竟你不会直接把数据库中的数据返回给客户端，也不会直接把客户端发来的数据存入数据库。
肯定要加

一层数据校验 用于接收客户端消息
一层数据打包 用于给客户端发送消息
一层事件发送 （可选），用于hook，或者统计

你的意思应该是 这么多层 你都想用同样的方式， 比如json， 而不想各种格式都有 对吧？



还有 其实说的那些 JSON SCHEMA 格式校验，
我觉得根本没必要。

无论是客户端还是服务器， 对于接收到的消息， 按照 预设的方式去解析， 如果解析出错
直接报 消息格式 错误就行。

@neoblackcap

以前看过，觉得有点复杂， 就没再研究了

@dcoder

我倒不知道有个 json-schema 来规定这种事情

不过我以前自己想过类似的实现：

{
"version": xxx,
"fields": ["a", "b"],
"a": xxx,
"b": xxx
}


带有 version， 这样在一定程度上做到 不同版本兼容
fiels， 就是来说明这个 json 有那些 key 是带着数据的


就如同你说的， 规划好了， 其他方式也能做到这样

@est

感谢推荐 ，不过非主流格式 是从来就不会考虑的。
毕竟 是要在不同语言之间 交换数据的。 所以还是得用 通用点的

@clino

恩， 我的意思是
1. msgpack 和 json 一样， 不用先定义 协议描述， 直接 序列化/反序列化就行.

那么此时 json是内置的， msgpack 还要安装第三方库。 这时候就没有json 方便了。

2. protobuf 和 msgpack 都要安装第三方库. protobuf 的定义文件，就是协议文档。
在多人合作开发的时候 有优势。 json 和 msgpack 还要自己再写一边文档。

@avastms

> 因为要传key值所以效率不如protobuf

你是指 bson 吗？


没明白这句话的意思 ，求详解

@clino

至于 python 的 protobuf 比 json 慢，
是因为 以前看别人也说过 官方的 protobuf 库 效率很低， 但没说有多低。

我也是一测，才发现居然这么慢。。。

@hewigovens

flatbuffers 也关注过， 但是目前 支持的语言太少， 比如就没有 erlang binding

我暂时也没时间去自己写一个。


还是用用其他现成，成熟的吧

@znoodl
@clino

msgpack 以前也试过， 感觉不到它的优势

比json / bson 并没有多大优势。 反而又多了一个 私有协议。

@dcoder

感谢 推荐， JSON.NET 已经加入我的 unity wish list了， 不过还没购买