@cqcn1991 解析数据才是难点。。
对于那些点，除了三维坐标外还有这个点与另一个点的连接参数。绘制截面肯定绕不开这个

@leeyiw 没说明兼职做嘛。。囧
说回来两周->14天-》1小时/天-》14小时，不够啊

真要有这样的数据的话遍历一次不就行了么？

感觉这货最靠谱的应用应该是高精度的三维雷达，但是作用距离有限。

@jadecoder
网页20个小时感觉不太可能，细节坑太多，C#直接做界面20小时还有可能。
python对接那些快递公司接口单纯入库的话两个小时差不多，这事上PHP反而耗时更长

@leeyiw 你的月薪就2000？

@snopy
场景是web，还是其他？
web的话不建议这么做，其他环境自行定断，原因都是防火墙/NAT截断数据流
另外你给的说明几乎是没任何帮助意义的。。
因为涉及到不同的环境不同的场景对包的处理方式有所不同。
最简单就是开个SOCKET并且设定SO_KEEPALIVE。
但对于KEEPALIVE的一些参数，如检测间隔重试次数等的设定，在win和linux是不同的。

另：这种方式在复杂的网络环境下不保证可用，但这是最简单的做法。
连接本身一直不close就是长连接了，但往细的说这是个坑，要考虑的事情还挺多的。

@geeti
一两个小时绝对不可能，从0起步的话数据库逻辑都写不完。
而且要求的是网站，即便带上框架，各种字段的布局，CURD页面，各种HTML布局是个体力活
以及这部分的用户界面逻辑也是另一个体力活。
每一个请求独立的数据验证，这是另一个体力活。
看起来事不多，但是做起来要考虑的就多了（很多时候这类系统都是体力活。。囧）


@poison501 赞同@hiv2itsme ，价格绝对会让你觉得excel还挺好用的~

@FastMem

http://medoo.in/api/where
在这一页

虽说我没用过，但是人家文档中的写法是 "LIMIT" => [20, 100]

其实对于这种云服务，我是非常的不信任的。
这种云服务就是把网站的数据、逻辑与服务商绑在一块了。
服务商靠谱还好，服务商不靠谱的话其实灵活性还不如自己维护服务器。

@snopy
应用场景呢？不然我们怎么告诉你怎么用。。囧

nomachine 能看视频

TCP Socket长连接无法保证，因为有奇葩网关会不发RST截断数据流。
对于这种已经断掉的数据流来说，底层的Socket会阻塞在read上。
（情况与断网类似，需要等待TCP超时）

具体长连接实现与应用环境有关，请提供应用场景以作判断。
一般建议手工发送keepalive数据以维持连接。
（那种奇葩网关也会忽略TCP的keepalive包，所以要手工发）

hello world 还挺好理解的。。
冒泡就算了。。囧
字符都显示不全

@demonchang

读消息表拉取消息，读了就给已读表写一个状态就好了。
状态获取用join能很快的实现，性能问题忽略
其实一般全局消息不多，分开查询也是可以的

映射表做法算是最合适的做法了吧
消息表：
消息id，发布者id，内容，时间，更新时间，状态

状态表：
用户id，消息id，状态

对于全局消息，直接读消息表，对于部分群发消息或对于一对一消息，读状态表

@wushichun
既然前期网站优先APP靠边，那么Win也不是啥大问题。
乔思伯机箱/恩杰机箱+T7000+/HP 5K/DELL P2415Q（4K）屏幕+支架还是挺好看的
要是配置的时候注意下，这种配置上黑水果也不是啥问题。（虽说外界看着不太好）
初创公司还是别在这事上花太多了，拿到投资再升级不迟。

Web开发我个人选择（其实是家里的环境）
E3+16G内存+240G SSD+T7000+双屏（用微单校准）
外加一台独立虚拟化测试机

数数优点缺点
优点:
开发机性能好配置好
双屏提高工作效率（我家自用是3屏，U2311+(T7000+)+U2311）
独立测试机跑ESXI（配好模板以后建立快，恢复快，备份也快，还方便开发运行环境同步）
本地16G内存暂时够用，IDE+Chrome上百个页面压力也不是啥问题。

缺点:
价格较高，测试机是i3+240G ssd,整套下来2500不含机械硬盘，PC单主机就4K，配上显示器。。。
算下来价格和RMBP 15港行很接近

不过其实测试机是可以共用的，独立配个E3做测试机，挂个GEN8做ZFS R6储存也是个不错的选择。
这样能省一些。。还安全~

至于后续IOS，直接为IOS工程师独立配顶配rMBP15+双屏好了
顶配rMBP15的处理器性能接近E3

@kikyous
windows: PingInfoView
linux: 写脚本

搜索引擎关键字： 批量 ping