论坛说简单简单，说复发复杂的，关键是你这个东西有没有未来，如果未来比较渺茫就简单点好了。

真正在意Typography的会加上1/4个空格符号。

吐个槽也变成作案了？

condense？求谐音有些奇怪

培养目标客户么。不如来用blender

supervisor

扔掉烘箱里？

我虽然码的代码不多，但是有个现象：那些所谓的代码原型，如果一个星期没碰，我自己看懂都很难了。

所以，哪怕是为了自己，也要不断地把代码整理成最优美的样子。

说一下我们这边的想法。

首先，这是一个学校项目，而且目前还找不到足够有能力+有兴趣的小伙伴来完成，基本上就我和另一大牛YY中。

传统些，而且成熟些的分离方式是前端写后端模板，后端填数据，浏览器还是取页面。这种方式对一个比较成熟的团队来说更加问题，改造代价小；而优势也是显而易见的。

激进些，就是前端完成渲染，后端传数据，而模板和渲染代码都是静态的，由Web服务器搞定，大量的缓存可以推向前端。这样需要前后端之间定一个API。后端实现这个API，前端使用这个API。这样进一步带来了灵活性：后端可以是不同的平台，很容易扩展到多服务器；前端也可以是多平台。我们的应用有考虑到移动端的支持，默认还是开发一个适配移动端显示的HTML，但是由于API开放，相信以后会有其他的小伙伴有兴趣完成移动端的原生App。

然而这一激进的方案也有比较大的问题：目前API设计（我的主要工作）就是难点，由于业务逻辑有些复杂，单纯使用REST会使得有些业务需要多个API调用才能完成，从而产生原子性问题，需要引入状态，这又与REST的stateless设计冲突。另外，渲染代码和业务逻辑代码都由前端完成，使得前端的要求过高，学生中恐怕会难以找到hold的住的人（现在就是找不到人的状态啊！）

所以，有了第三套方案，即基于node或类似比较“轻”的技术来实现中间层，中间层负责业务逻辑，把多个RESTful的内部API调用转换成单一API的外部API调用，从而减轻传统前端的压力。这样，前中后端分别负责交互、业务、数据，缓存更加推向前端，缓存级别增加，同时系统解耦增加，代码逻辑更加清晰，维护性增加，扩展性大大增强。

但是，这第三套方案需要有两套API，精确定义两套API的转换方式（等于手写一遍业务逻辑），且可能设计过于复杂，具体实现时的编码、调试工作都会增加，我们本来就没几个人，怕是折腾不起这样一个系统。

另外，由于是学校内部项目，没有SEO和带宽方面的要求。

用MTR发现丢包80%以上的都是在中国电信美国节点

电信就是把大家都在用的出口流量按IP分了优先级，加收点钱叫精品网，普通用户本来也不快，现在自然是更加慢了。
我这里上个月也就平均60%的丢包，现在已经75%了。

kerbal space programe
神作，虽然收费

刚好有安排了，虽然在玉泉附近还是来不了啊！

屏幕的像素对应的应该是声音的编码频率，而不是动态范围。

声音的编码频率早就超过人耳了。

不论这个，我的旧本是13.5的1400x900，新本是15的1366x768，已经体会到了清晰度上的差距了。

H.263是专为实时设计的，压缩率不高就是了。