屏幕不适合思考。诱惑太多。
哪怕你用了禅模式，功能依然多。
全是干扰。

对我来说最好的思考就是纸笔（专注模式量产成果），或者洗澡散步开车（暗时间+灵感突破屏障）。

to:([email protected]) 创建一个过滤器。

但这样误伤非常严重，很多订阅邮件都不会写明收件人的。酌情。

关于词的形成和发展。我一直对这个很感兴趣。
以下一半是考古，一半掺杂我的猜测：

handle，是一个编译原理的概念，指的是一个句子中最先被规约的部分，所以带有一个「句」字。
后来文件操作编号叫 file handler，其中的 handle 借鉴之前的 handle 那个翻译，直接就叫文件句柄了。

单点登录，对应于传统多个网站 /应用需要分别多次登录，单点登录只需要在一个点登录一次就可以在多个系统中使用。这个词其实很好理解，近乎白话了。我猜 lz 感觉莫名主要是不知道这个是什么东西解决什么问题。

2b/2c/saas，to business users，to customers, software as a service，非常精准非常传神的定义的缩写。只是对领域不熟悉才会陌生吧。

其实纠结一下这些词的来历挺有意思的。有些可以挖出历史，有些可以深刻理解，有些纯粹是好玩（比如鲁棒性哈哈哈哈哈哈我可以笑三天）。

随便抛几个大家耳熟能详的词吧。
身为陕西人，我居然很久都不知道陕西为什么叫陕西。
鼓舞士气为什么喊加油？这词出现可比汽车要早。
大部分人都知道没有马的路为什么叫马路，但未必知道没有马的桶为什么叫马桶。
我总是很喜欢美女留刘海的样子。那么刘海这词是怎么来的？怎么听起来那么像姓名？

也许有人会觉得这些知识是“垃圾”，穷究这个是有“毛病”，但垃圾和毛病是怎么来的如何会发展成现在的意义？

这么视角一看，生活中一堆堆习以为常的事情瞬间就其乐无穷了啊。

非必要的时候还习惯打./ 的同学。。。
你们不怕.忘记打或者.和 /之间多敲了个空格吗？/狗头

谨慎是好事。
但谨慎也是负担。
过度谨慎也是过度负担。
但话说回来，负担是有上限的，因为你的精力有限，deadline 也有限。而且长期来看，可以通过水平提升来提升自信，通过方法论来降低成本，从而降低负担。
而谨慎性格本身却是非常难修炼、改变的。

所以综合来说，你这是好事啊。。。自带优异属性，额外成本又可以通过后天努力来消除。
相比那些缺乏严谨思维做事毛毛糙糙的程序员来说，先进到不知道哪里去了！隔壁老板和技术经理都馋哭了！

法律不认，但舆论认啊。
当前舆论比法律有效。
so，还是录下来靠谱。

如果不走歪：
相对坐着，站立更容易缩短时间，更容易集中精神。
每日集中、扼要的进度同步和协助请求是极好的。

但有人理解不了项目管理的核心概念，瞎 jb 搞，很容易走歪：
罗嗦。每个人絮絮叨叨讲个没完，尤其还有喜欢表功、喜欢鸡汤、喜欢跳忠字舞的人。——控制每人讲话时间和内容，半分钟足够了。一两句话讲不清楚的得考虑组织个讨论或者会议了。
走题。昨天做了什么（同步进度），今天计划做什么（同步计划），需要什么协助（抛出问题请求合作），除此之外别走题了。扯太远的事情应该组织茶话会。
批斗。信息同步是主旨，不应该成为批斗大会，不应该带来巨大压力。压力是肯定会有一点点，但应该尽量避免。一项措施的成功推行与否取决于所有成员是不是意识到这件事的正面价值。都是负面价值，那这项措施肯定推行不好，不是敷衍了事就是形成负担。

所以，晨会的组织者（项目经理、Scrum Master ）是最重要的核心。让 lz 这么生不如死，你家团队的晨会组织者要负责。

我现在浑身四周都是藏经阁，什么 SICP 什么 TAOCP 各种武学秘籍，但这不影响我继续是一条咸鱼。

说起藏经阁，2000 年前后藏经阁出品的盗版游戏光盘更让我无法自拔。

token 设置合理有效期，确保一次登录≈一次授权。
那么授权 token 的时候记录一下就可以当做上一次登录时间。

如果服务端管理 token 生命周期的话，提供合理的 token 刷新机制。
如果 token 自描述生命周期的话，客户端一起参与实现 token/refreshtoken 机制。

日志汇总吧，并发请求就会交错起来，不方便跟踪一个请求（一个业务）的日志。
按请求分开吧，日志之间的时序关系就会丢失，不方便观察服务器状态，尤其是一些请求无关的全局的状态和资源。

各有利弊。

我的做法是：
1，默认日志按时序，需要的时候用 requestID 来过滤就可以方便的按照请求来查看日志序列。全局时序也方便日志切割、轮转、储存、查找等大部分场景。
2，关键业务日志独立，按业务来冗余记录。比如一个用户 /一个订单的所有日志。
3，以上两点结合也比较方便。输入还是正常输入，输出独立多个 Adapter，按不同规则去路由到不同文件即可。

先做原型。哪怕是草图，也得把核心逻辑、交互想清楚。
然后是模型，模型出来了，数据库和前后端接口也差不多出来了。
之后前后端就无所谓先后了。

答：技术原因真的不存在。就是商业策略。人为造节日也是营销策略，各种广告也是营销策略，错综复杂的优惠券也是营销策略，尽力避免退货退款也是营销策略。
所有的商业行为都只有一个核心：人傻钱多速来割，在法律框架内（？）尽可能的实现利润最大化。

所以呢？知道答案以后呢？下一个双十一你还陪玩吗？

@NGPONG 单应用单场景，直接 tinyproxy 打发掉了。：D

我司和合作方也有类似问题。他们的亚洲节点在 AzureHK，直连访问会很慢。

方案 1：Azure 中国（世纪互联）开个接入点，在 Azure 内开个加速通道。名字忘记了，但有这个服务。（贵，合作方不肯搞）
方案 2：我们自己买了个阿里云 HK 做代理，代理 AzureHK 速度还是很快的。成本也低，低配机器大带宽就好了。（现形方案）

小厂子，简单实现，满足需求够用就好。

做普通人都已经累成这怂样了，你确定你可以通过学习来精通操作系统、编译原理、算法、系统设计等任何一个方面成为大神吗？

安安心心的继续怂样就可以了。/狗头

@zengming00 不能这么算吧。。。否则但凡上亿的软件根本没权利做减法了？就像 QQ。
重要不重要数据说话嘛。砍了标签页估计接近 100%的人要叫，但 2%。。。GoogleReader 还没哭活过来呢喵了个咪的捶桌。

@Mutoo 我第一反应也是 SCP 文。