@baichaohua #18
我本来想说：才发布也没多久啊，真的会有人这么快就出 16 寸嘛？

结果就看到交易区有人正在出： http://v2ex.com/t/666979

补充一下关于 100Wh 的电池感知不强。

可能因为我总是会用到涉及独显的程序，所以不管是以前的电池还是现在的电池，基本上都是 3 小时内就 GG ……

对比我那 72Wh 能抗一天的 gram，前后都只能感觉到 『续航太差』

对我来说，我大概在 19 年年初就有换新款 MacBook 的打算，但是苦于键盘的问题一直不想下手。

所以 16 寸解决了键盘的坑以后我立刻就种草了~~

14 款 15 寸换成了 16 寸，目前的感受是如下：

扬声器实在是太给力了，看评测的时候感受不到，实际使用的时候很惊艳。
键盘！我之前一直不换新款就是因为不喜欢『微动开关』一样的键盘。


风扇似乎比之前更安静一点，应该是因为我的旧款风扇有积灰。
理论性能提升感受不太强烈，但是明显感觉降频的情况变少了。


多出的一寸感知不强。
100Wh 的电池感知不强。

@alier #86
单纯从你这个回复来看，你的老大做事确实有点不地道。

1 、没处理好离职员工的交接问题，埋下隐患（即使裁员决定不是他做出的，也应尽量处理交接问题）
2 、不主动处理棘手问题，将问题直接丢给小兵处理（技术小兵已经明确表示存在问题，还不升级处理）
3 、与其它部门的交流中不『护犊子』，将小兵推出去挡枪（哪怕是策略性的推出去，至少也要私下安抚）

冤有头债有主，按照你说的内容来看，这才是债主啊。
从这个角度来看，离职是正确的决定。

如果我自己牵扯到类似的场景，我可能会按照下面的方式来处理。

对运营小兵：
自己力所能及的事情就处理，不能解决的，或者需要与已离职同事沟通的，就如实阐述问题。
如果对方死缠烂打一定要找你，可以明确表示请对方直接找自己主管。

对运营主管：
大家不是一条线，你管不到我，请找我的主管沟通。

对技术主管：
这个问题需要已离职的某同事协助，请帮助我沟通一下，否则我无法处理。

对已离职的同事：
在公开场合按规矩进行询问，最好在主管在的群内，如对方不回应或有其它不满，请对方找主管解决。
有私交的人，可以在私聊中讲清楚不需要给自己卖面子，大家按规矩来，不愿意协助就不协助，不欠人情。

@alier #59
我感觉其实挺难判断运营是否有做错事情的，朋友圈的事情，看起来之前还有类似的不愉快沟通？
这样一直追溯下去挺没意思的。

如果运营确实在交接这件事之外，做了其它不合适的事情，那确实运营不合适。
但是单纯就交接引发问题这件事来讲，不是运营的责任，还是那句话：冤有头债有主。

纠错，44 楼 『如果运营小兵认为存在自己无法解决的问题』
应修正为 『如果开发小兵认为存在自己无法解决的问题』

需要强调的是，楼主自己也是受害者，也挺无辜的。

其实很多 老板 / 主管 自己心里清楚找已离职的员工寻求帮助很尴尬，所以才故意指派小兵去做这些事。

但是冤有头债有主，将怨气重定向到其它人身上，挺烦人的。

不知道之前的沟通是怎样的，单纯就这一次沟通来说，我觉得楼主其实可以改善一下自己的交流方式。

运营主管 → 技术主管
↓↓↑↑----↓↓↑↑
运营小兵 → 技术小兵

当运营小兵遇到问题的时候，肯定是先找技术小兵来解决，对于运营小兵来说，他可能并不知道这背后的弯弯绕绕（他也没能力去解决）。

如果运营小兵认为存在自己无法解决的问题，应该明确反馈自己无法解决。
这时，可以由开发小兵将问题直接反馈给自己的主管来解决，也可以由运营小兵将问题交给自己的主管来寻求技术主管的支持。

技术部门内部交接产生的问题，应该由技术部门的主管来背锅，而不是运营小兵。
如果因此影响了对运营部门的业务支持，那运营主管大可继续向上打官司，让技术主管来彻底解决问题。


总而言之，运营部门，尤其是运营小兵在这件事里挺无辜的，不应该承受这些额外的压力。

分开。

在现在 SPA 盛行的大环境下，将后台页面塞进同一个 SPA，会暴露很多后台功能和接口（虽然大概率不能用，但是能看啊）。

某出版社的后台就有这个问题……

@Anhedonia
我的目的就是这样…
但是用鼠标的话有时候很难控制…

楼主今天在死磕 CAP 啊………

补个链接：
https://theunarchiver.com/xee

一直在用 xee，也购买了正版，但是好像已经很久没更新了，在 10.15 下使用偶尔会卡在启动过程很久。

借楼提问：
OneNote 是否可以强制不随意排版……

https://i.v2ex.co/504J5BO2.png 你可以试试用自己的锁屏密码，去 Safari 里查看下自己的 Apple ID 密码

@xiadada
对，这个事儿其实就是看业务场景，业务场景能接受那怎样都好说，

在日常状态下，这样其实吸取了两边的短处，性能、流量都有更多的压力。

当然，并不是说完全否定这种模式，如果有这种不太严谨的业务场景，那用用倒也无妨。

本质上来说，其实就是分了两种状态。
在日常状态下，将 client side session 的 session data 作为 server side session 的 session id 使用。

在 Redis 挂掉等奇怪的状态下，退化为完全使用 client side session 机制。