其实这事没什么好辩论的。开源协议不是什么严丝合缝的法律条文，选择它时也没有什么特定的法律程序，双方都说得有理有据，要真拉扯双方都有拉扯的空间。天猪也说了本来就是很简单的事，说一声双方都知道就得了。

现在主要矛盾是天猪觉得 LZ 把他挂到 V2 上来害他被骂了，他要采取措施。建议 LZ 私下与天猪协商，事后让坛主把帖子删了得了。

我看了 Mix Space ，也看了保罗的小窝，有一些结合了个人经验的看法。

我没做过完整的前端 UI 方案，但做过 Discuz 的插件跟局部 UI 修改，恰好 Mix Space 这种板块布局风格非常像以前的 Discuz 二次元主题，我想可以说些什么。

由于主题叫 Kami ，加上 demo 标题，这应当是一套偏日式风格的 UI ，但我感觉到一些违和：

1. Helvetica 极其平淡，使用日式风格字体更好，比如一些黑体、细长体与细圆体。

2. 白天模式下的背景白对比过于强烈，造成阅读不适，可以换成温和的大色块。夜晚模式要好一些，但背景的横线仍让我不禁想起 QQ 空间中的“信纸”，有一种廉价感。

3. 透明底的控件不好。博客要设计得有层次感，一是突出内容的类属，比如正文、回复框与评论，降低读者的“负担”，二是反衬出背景，不致于文字与图像无序杂糅。

4. 减少色彩的使用。这个就不多说了。

5. 论坛式的板块布局不适合直接用于文章陈列。弊端很多：
- 无法从有限的板块宽度中提取完整的文章标题；
- 文章配图局限大；
- 横向空间利用率低；
- 整体有效信息密度低

就信息密度低多展开一下。无论是博客系统还是论坛系统，重要的还是有效信息，风格再强烈，该传达给读者的还是要传达的。所以除了纯炫技的飞机稿，非主要的图片元素喧宾夺主是打造主题时很忌讳的一件事。

希望 LZ 的项目能越做越好。

看了 Pixcall 的官网，有些东西可以说一说。

我建议你先对 Pixcall 和 Eagle 的官网做一做各级标题的词云分析。
Pixcall：“云端同步”、“本地客户端”“图片优化”、“浏览器扩展”、“客户端插件生态”、“免费”。
Eagle：“素材整理”、“激发灵感”、“快速找到收集”、“轻松整理”、“流水般浏览”、“用户喜爱”、“媒体好评”。
Pixcall 的主流服务群体是谁？是设计师等一众呈现视觉效果的群体，TA 们感性度更高，更受用表达情感的抽象名词而非技术名词。
你希望它是一个“硬邦邦”的工具，还是“柔软灵活”的助手？

同样的角度，动效的表达大于静图，内聚的表达大于宽放。就不展开说了，个人觉得 Pixcall 官网的内容及排版需要更加专业、有倾向性的设计。

然后我想讲几点关于竞品的理解。
（这里只是针对策划已知市面上已经存在同类产品的情况）

“凭什么抛弃惯用的 B 来选择你的竞品 A”是在产品立项的时候就要作出的思考。未雨绸缪利于在关键点上对症下药，如：
用户觉得缺少平台支持--使用跨平台、移植性好的技术。
用户觉得软件不够灵活--模块化、增加插件机制，甚至（部分）开源。
用户有路径依赖--复制竞品的逻辑与流程，大到布局、小到快捷键。

在运营端，先争取大牛背书，讲得一手好故事，有了基本立足点后借助各路大众媒体广撒网。推广与技术配合好，在宣传期降低活动准入门槛（别一上来就搞手机邀请码注册），筛选种子用户，做好反馈收集。接下来就是赶紧迭代，实在没辙了就修正赛道，在小众需求上实现弯道超车。

对于竞品开发，小团体对抗大公司可能只有一个有利条件：关键的运营人员、技术人员离实际用户“更近”，在快速反馈上有人员组织架构的优势。

确实跟 Twitter 风格很像，不过并不重要，如同 @yazoox 所说，怎么运营、怎么进行内容管理才是建设这类站点核心的地方。

Append 2

0X 年的时候写过游戏逻辑，技术可能过时了，就简单说说吧。

1. 不知道，这得问 LOL 的开发人员，不同游戏的 ping 代表的含义可能会不一样。
游戏内显示的 ping 值不一定是 TCP/UDP 的时延，也可能是专门为游戏设计的心跳机制中的网络参数。

2. 网络状况迥异的环境下，没有任何技术手段能确保双方都在某个 ping 范围内。
比起锁定延迟，我们更常的做法是在帧同步上下功夫，比如优先让网快的正常游戏，网慢的客户端对短时间内过来的更新指令作类似于快进的处理。

3. 不同架构、不同类别的游戏控制同步的方法不一样。
比如一款中心化的 RTS 游戏，采用的是服务器广播-客户端收发的方式交互，想要增加延迟可以设置广播队列的发送时间。对一款允许局域网内的 RPG ，纯粹的 P2P 通信，只需要交互前约定共同参数即可。

@littleylv 见 append

频繁地改需求，不外乎是以下几个原因：

1. 甲方对自己的需求不明确 或 乙方对需求理解有偏差。
这种还是挺有说法的，对口定制化跟不对口定制化情况略有不同。
对口定制化中，乙方在开需求会议的时候有义务引导甲方把需求漏洞补全；
非对口定制化中，需要甲方有人全程跟进，双方频繁沟通保持意见统一；

如果已经进入了开发期，有必要重新开展需求研讨会。

2. 甲方追加额外需求
甲乙双方在协商开发周期以及开发成本的时候就要明确额外需求的处理方式--优先级、费用、后续维护事项等。
一旦写进合同，照章办事。甲方来新的需求，乙方负责人会议评估，一致通过的话可以进行排期。如果不通过，对甲方反馈再作协商。

这里面有一个非常重要的点：甲方的需求不能直接到具体的编码人员，中间必须要有项目经理跟技术经理作评估。乙方需要有立场的独立性。


甲方是不会有直接的感同身受的，乙方需要维护自己工程师的利益。如果乙方只会两头吸血，那么 run 就对了。

对于已经语义化了的变量，我有一种评判代码逻辑组织是否合理的方式，即

用自然语言去试读代码是否会让人感到冗余。

从这个角度来看，我是同意 LZ 的说法，比如 if isOpened == true (假如 已打开 为真）就不如 if isOpened （假如已打开）。

之前好像回答过类似的问题。

一言蔽之，在体制内工作容易缺乏职业自信。原因懂的都懂，不赘述。

裸辞跟骑驴找马哪个好，这无法判断，很多事确实只能等到“盖棺”才能定论。但有一个事情是没错的，无论作了哪种选择，都要付诸相应的努力走下去，瞻前顾后、反复横跳是大忌。

既然是挂在网站上作个人展示，就不要拘泥于纯文字描述，可以发挥网络媒体的优势，增强一下读者的视听感官体验。

因为你也是 Web 工程师，前后端都做过。不妨：
- 做个个人经历的 timeline ，突出从学生时期到职人时期的里程碑节点。
- 对项目介绍作可视化处理，比如小程序的动图+动效展示。

个人网站一般是第二入口，即大部分点进去的人是“对你有点感兴趣”的对象，他们可能从别的地方（投递的简历 /论坛的贴子 /Github 的项目代码）知道了你，然后想进一步了解你。因此我觉得在里面感性的建设是必要。

最后是个个人看法：开源出来的东西尽量把 README 写好。
我注意到“喜欢编写健壮的代码，编写会以牺牲性能来提高可读性的代码，因为代码是给人看的”，从工程的角度看，纯叙述性的项目描述也是可以提高项目可读性的。

...给后来的人总结一下：

LZ 面试了一个图形工程师，感到不快，原因如下：

对方背景似乎很牛，但对于 LZ 的核心问题没回答到点子上。
从对方的话语中得知他只想“找大牛抱大腿”（可能还有点不愿意做一线实施的意思，仅个人猜测）。

我试下解读你的需求：
你希望搞钱，但在青岛当程序员工作内容平庸，工资也平庸，想要改变的时候发现自身资质也平庸。

这跟 CRUD 本身没什么关系，就是没有立身之本、缺乏职业自信造成的精神内核不稳固。

我的建议是先作自我剖析，认清自己，再决定接纳还是改变自己。

其实你说的不是什么新鲜事儿，就是一个渠道管理的问题。

在 app 运营的最初期，你的推广渠道够不够多、你在推广渠道话语权够不够大是很关键的。

菜市场的格局已经从堆数量的野蛮生长期过渡到了保质保口碑的成熟期，在这里面，个人小开发没有自主能力。
除了海外渠道，经营私域是最常规的玩法：业务 app 上小程序、云平台，甚至只是打个 apk 包挂到 XAMPP 上。用威推抖油等还有原创红利的新媒体导流。

先去大公司，让前老板给你留个坑。

我从另外的角度提供思路：

你在读研中有没有新的领悟？没上岸有没有觉得可惜？

认真过了，还是差得远，不妨更换赛道，你的长处就不是在这，方向错了越坚持越尴尬；
没尽力，得过且过，也不需要继续。你需要改进的是生活态度，先找工作，俗套地说，从一点一滴做起；
认真过了就差一点点，那就总结经验再战个痛快。“我本可以”是天底下最大的遗憾。