游戏要进入中国，困难不少，下面是我想到：
1. 要给广电审核，这要好几个月吧
2. 地图数据来源。 现有的地图数据来源比较神秘， 最大可能是来自美国政府的一个不算完整地图数据， 但未经证实（[来源]( http://www.theatlantic.com/technology/archive/2016/07/where-did-pokemon-go-get-its-map/490799/)）。这个地图对大陆部分的缺失或许较为严重， 想进入中国还要和国内的地图提供商谈。即使谈好了， 还要花上不少时间加入的 app 里面。
3. 服务器也是个问题， 那么大的游戏， 那么多用户， 我想只有在境内才能保证好的体验了，这又要和服务器提供商淡。
4. 国内或许很快有山寨品。不小心让对方给告了还很麻烦。 这又要和各种相关部门办各种手续。

保证好目前的运行，已经很不容易了。 真还没有那么多时间发展中国市场。

可以去运动呀。例如可以去找个之前没有接触过的运动学下。就是去玩玩，这样你也可以认识些朋友。

试下：
sudo apt-get update

如果有
1. “ Hash sum mismatch ” error and
2. "GPG ERROR"

就执行：
sudo rm -rf /var/lib/apt/lists/*
然后
sudo apto-get clean
sudo apt-get update

答案来源：
http://askubuntu.com/questions/575639/cant-get-anything-to-install-dependency-errors
http://askubuntu.com/questions/41605/trouble-downloading-packages-list-due-to-a-hash-sum-mismatch-error

最后想了想 刚刚提到的方法 应该行不通，因为我好像看不到怎么在客户端改 DNS 端口

如果自己有 vps ，自己架设 DNS 之后设置端口为非默认端口，难度应该和自己玩 ss 差不多。 教程应该不难找，记得鸟哥 linux 教程不错

这个问题可以说是很大的。 查询优化是否规定必须在 mysql 之类的数据库里的查询优化呢？如果不是，范围就广了。可以和面试官聊一天， 如果你想的话。
从最底层的服务器架构说起，各种云服务器的选择和配置
数据库的选择（ Sql ， NoSql or both ）， 配置（ cluster ？ 是否 shard 或者 replica ），以及和他们相配合的数据结构和查询语句的优化，
一直可以说到前端库的选择。
甚至可以把数据丢给前端，直接在前端搜索

上面的每一步都可以对查询的速度有影响。有空的时候可以看看对于哪些问题，会有哪些对应的技术解决，有些相应的了解也是不错的。

其实有没有想过在 digital ocean 那里或者自己的 vps 上安装个 ownCloud ？ 我自己是没有用过，是有点折腾，不过可以值得一看，多个选择而已。

你可以上网查或打电话到客服问下。有些笔记本在开机时有单独检测屏幕是否正常的组合键。 我的 Dell 有，不太清楚联想。

设计阶段也很重要（各种 UML diagrams 和 use case ），因为在设计阶段，应该能看出部分代码逻辑需要重复使用，从一开始就预防。当然，之后还要加上楼上提到的 review 之类的。
原来的代码重复就重复吧，除非公司给出时间让优化什么的。但新的功能的话 就好好好设计和 review 了

很多 php 框架都是 MVC ， 他这里应该指的是这里的‘ V ’吧。

@DoraJDJ 写入官方文档了 应该不会有什么问题。如果真有问题，你可以提交 bug 的~

这个吗？
request.headers.host

同意楼上。反正现在的不少 web app 都要有 mobile app ， API 迟早要写。所以可以慢慢迁移到 angular react 之类。我目前是 Smarty 和 angular 混用，只是过渡方案。

不管怎么说 不配显示器这点，公司的表现肯定是被扣分的，以后肯定还有很多事情让你觉得公司吝啬的地方，就看你自己容忍的底线了。多周围看看咯，你的底线也会不断调整，这就像商品价格，市场决定

我怎么感觉处理数据这些事情应该给后端做？ 没有 code 还是不能判断 但处理数据什么的至少也可以丢给 factory 去做吧

@daybyday 的方法是一个方向，在他方法的基础上你还可以参考这篇文章，看看如果要 filter 各种数据的话， redis 应该做怎样的设计。
文章链接： https://robots.thoughtbot.com/redis-set-intersection-using-sets-to-filter-data
有一点难度，但用好了 filter 的速度很快。

还有一种可能比较粗暴, 没有那么好， 但还算简单的方法。
我假设你 Article 内容本身不在你的要计算和分析的范围，那就可以将 Article id 和各种需要计算和 filter 的 column 单独放个 table ， 每次只是查询那个 table ，过滤、分析得到 id 集之后分页， 接着再去查那个真正的 Article table ， 这样内存的占用应该少很多了。

对于一些小功能， CTO 只给我数据库的 dump sql file 和大概说下 use case 就开干了，我要从数据库导入，后端，一直写到前端～
感觉文档有就都给 前端可以选择性的看。至少有个大概的概念吧。
然后 API 接口什么的怎么说也要看吧 要不怎么传数据呢？