表格移动的功能都没有，很难替代标准的笔记编辑器啊。

初学上手 Deepin 啊，估计初学者上去还离不开 QQ 什么的。

24 寸 1080p 不能算高分屏，普通分辨率，字体显示效果本来就不会太好，Windows 下也差不多。

有些服务商（比如百度)提供 IP 到地址的精确定位服务，说不定在不经意间你的代理 IP 已经被关联了真实地址。

"不低于原产品性能的同品牌商品"，这个可操作空间很大啊。同品牌好定义，不低于原产品性能就比较难定义了。

在手机上用微信里的京东购物（逃

感觉去牛校牛组学的技术：要么就是特别新的新技术，还在原型探索阶段，离商用还很远；要么是离商业环境差很远的旧技术，毕竟学校的硬件条件和数据都赶不上公司。
不过学校里面有个很好的优势：允许你*有时间*涉猎计算机的方方面面；而且可以通过撰写论文，来学习从提出问题到解决问题再到向别人解释自己的工作这样一整套流程，在学校有时间和机会进行试错和尝试，还有人指导。

微博的技术大拿在网上有技术分享 PPT，应该还能搜到。
我印象中，当时的 PPT 是这样说的（约至少 2 年前），如果说的有问题，还请拍砖：
1. 微博信息数据（即微博的具体内容等）是存储在关系型数据库中的。使用标准的分库分表技术就能水平扩展。
2. 微博的关系数据（即 Follow 关系）和 Feed 流数据，我记得没有细说。但是每个用户是会维护自己的 Feed 流，这个 Feed 流应该只保存了微博 ID 编号，不保存具体微博内容。等用户浏览自己的 Feed 流的时候，再从关系数据库中取出微博内容，并将网页返回给用户。
3. 微博的通知数据（你有 XX 新粉丝，有 XX 新回复，有 XX 新点赞等信息），因为体积不大而且经常变动，是保存在 Redis 中。

当一个用户发了一条新微博之后，后续的更新动作一般是推拉结合：
1. 对于普通用户（粉丝数小于某个值）的微博更新，用“推”的方式比较划算。当一个用户更新微博后，把新微博的 ID 信息写入他的粉丝的 Feed 流存储之中。
2. 对于大 V 用户（粉丝数大于某个值）的微博更新，用“拉”的方式比较划算。当大 V 更新微博后，并不会将新微博 ID 推送到粉丝的 Feed 流。而是在粉丝查看自己的 Feed 流的时候，现场去查询其关注的大 V 的最新动态，并加入 Feed 流。这种“拉”的好处是减少了大 V 更新微博时的一系列数据库操作代价，而且大 V 微博的时效性很强，能很好地进行热缓存。

@zuolan 这个项目看起来有些厉害

上一季已经暴露出各种内幕了：魔方赛、海藻画等。看起来炫酷的挑战，看起来强大的不得了的观察能力，最后被发现就是提前背题。所以这节目当娱乐看看就好了。

QQ 自带相册助手，挺好用的，基于 Wifi，传过几十张图片，没问题。

虽然小米的相机不行，但是锤子的相机应该更赶不上小米

但是这维护一点公告都没有

手机双拼用全键盘模式，感觉还可以。就是有时候按错键了，修复比较麻烦

58 Nightly 在 Windows 下速度嗖嗖的

@jinhan13789991 我这边的 VNC 没觉得卡，还挺流畅的。本机操作，VNC 网络带宽不是问题。

@jinhan13789991 哈哈，只是个人的一点小经验。现在 Docker 直接和外面的 X 桌面集成，有些复杂。现在我是在 Docker 里装了一个带 VNC 桌面的镜像，通过 VNC 连接到 Docker 内部进行开发。Docker 内的系统版本和服务器上的一样，确保本地编译的程序能直接部署到服务器上用。

煎(jian)蛋(dan)

现在就在 Linux 下用 Docker 搭建和开发环境，比开一个虚拟机省资源多了。