如果你要按照出勤日计算，那么你不过多久结算一次，都是日薪，最终都是日结。在此情况下，保姆事实上具备随时第二天请假，以及随时第二天就走人的权力，不管你给不给这个权力。实际上来说，通常，能接受按日计算工资的保姆，也只会做短期打算。

要么日薪，剩下节假日的钱，但接受保姆不稳定的风险。要么月薪，节假日当作福利，但是保姆会很稳定。你要保姆长期稳定干，又不给人月薪福利，那是想吃屎。

你这个很明显跟 public static final int FIRST_LINE_HEIGH 没关系，跟 ScreenUtil.dp2px(80) 有关系。

80dp 的高度如果是静态值，那么请直接把它赋值给 FIRST_LINE_HEIGHT 。如果是动态值，那么请不要赋值给 static final 类型的「常量」，给常量设置一个可变值，即使是仅取第一次的值，那也是找抽。

你现在是装了一个权限比操作系统还高的超级后门，它可能确实没干，但它要想干随时就能干。

这种系统，有一个名字更贴切：（公司对员工）零信任防护系统。信任是双向的，公司对员工零信任，员工也要对公司零信任，在装了零信任系统的公司电脑上，不要放任何员工的个人内容，包括笔记这种零碎个人资料。

@wdlth #10 ip-guard 自己就明确区分了数据加密保护跟全盘监控两个级别，你还在这里混淆监控跟数据保护，那是连非蠢即坏都算不上，是实实在在的蠢。

搜索结果上的是摘要，快照是快照，这是两码事。

六，响应式编程，对应的编程概念是「流」，现实概念有个跟起非常像的，「流水线」。如果要搞这个，首先要把「流」搞清楚。Java8 的 Stream 可以用来入门。Kettle 、Spring Batch 可以用来练手。你最起码是 kettle 或者 Spring Batch （高级流应用，不能是一个处理器转发然后又回到普通代码去处理了） 用得比较熟悉了，才能去接触响应式编程。另外，你也可以直接从函数式编程、数据流，这些数学理论入手，不过前提是要先清空 C 、C++、Java 等全部常规编程习惯。

一到五跑题了，留着备用看吧。

一，同异步跟是否阻塞，不是一词两用，而是有关联的两个概念。

二，阻塞针对的不是当前过程，而是使用同一资源的多个过程之间的协作方式。通常都是 IO 比计算慢，故常见的阻塞是针对 IO 的阻塞。一个 IO 通道，如果只允许同时最多一个过程使用它，在该过程使用它期间其他过程只能等，那么这就是阻塞的。如果允许同时多个过程使用它，那么这是非阻塞的。

三，同步异步，针对的是调用者和被调用者之间的协作过程。如果被调用者不做完就不回复，同时调用者还一直等着它，那么这是同步的。如果被调用者没处理完就提前做个特殊回复，同时调用者认可这种特殊回复，那么这是异步调用。如果调用者这收到异步特殊回复之后，又再继续等待这个特殊回复转换成完整回复，那么这是异步之后的回转同步，或者，整体上来说，这还是同步调用。

四，再往外看调用者、非调用者的宿主程序，这时候同异步跟阻塞有了关联。如果把调用者宿主程序认为资源，调用关系——被调用者的执行行为认为处理过程，那么同步调用是阻塞的，异步调用是非阻塞的。

五，同步还是异步，技术上由被调用者决定，但业务上由有调用者决定。如果调用者实时关心回复结果，那么它永远要是同步调用，即使被调用者技术上异步，最终也要通过异步转回同步来变成同步。异步编程中，如何异步从来都不是关键，如何异步转会同步，获取去掉不必要的业务同步，才是关键。

大前提，如果你要区分同一个服务的不同节点实例，那么实例部署的时候当然要用不同的 bootstrap.yaml 。大前提，Spring Boot 和 Cloud 都不管部署（作为云服务的 Spring Cloud Foundry 另说）。

Spring Cloud 是允许你定义 instanceId 的，代码里面根据 instanceId 做区分即可。但是如何在 bootstrap.yaml 中定义 instanceId ，这个是部署的事，要 k8s 或者脚本去负责。

自增用户 ID ，除了暴露用户量，还能暴露啥。如果它本来就是跟用户原本信息，注册时空信息都无关联，只是人工关联上去的一串数字，那么它的信息量就是个代号。这时候任何静态加密，都是画蛇添足而已，不论加密多少遍，它都可以直接拿出来当用户的代号。弄个雪花 ID 或者 HASH ，将其外围统计信息隐藏掉，并方便存储优化即可。

你要真相搞隐藏用户 ID 的安全控制，那应该搞动态加密，即不同时空下的密文不同，还都能通过私钥推导到同一个 ID 。

一、标识、标志，并没有找到来源词根分析，这俩是现代新造词。二、标识、标志的区别不明。三、不论简繁，标准经常妥协与大众实际使用。这种情况下，翻译个蛋蛋。

第一步狗都能干。

第二步，将调研结果整理成产品子项；第三步，平衡用户需要和开发成本，选择做哪些子项：这才是产品经理的核心角色定位。独立开发者实际上很难抽出来产品经理得角色，这个真得找合伙人。

对于团队来说，如果没有第二步第三步，直接就拿开发加班顶上去，这事狗都干不了，得猪狗不如得“人”才能干得出来。对于独立开发者来说，不找个合伙人去给搞第二步第三步，那么非常大的概率是努力到头一场空。

虽然嘴上说着移动为主，但微软的主要营收——企业领域，以及主要非营收市场——盗版 Windows 领域，从来都没有手机系统的份额，导致微软在手机系统上的定位，一直摇摆不定，这是 windows phone/win10 mobile 死亡主因。诺基亚手机一买一卖静亏 50 亿美元外加彻底干死了诺基亚手机，做出这决策就跟玩一样。

一边给用户 100%的控制权——预装都可卸载、权限想不给就不给，一边又走廉价市场，让无良 OEM 厂商跟开发者既没办法赚土豪的钱又没办法坑穷鬼的钱，从而被 OEM 和开发者抛弃，这是 windows phone/win10 mobile 死亡最主要的外部因素。

绑定移动应用跟 UWP ，但 UWP 跟自家 Win32 应用相互干架，这是 windows phone/win10 mobile 死亡的次要外部因素。

友情提示，windows 10 mobile 终止维护时间是 2019 年 12 月，才 4 年前。

第一，谷歌从来都是打广告并且一直是把广告放到第一位的，这是正常的广告，跟百度竞价排名是由质量的不一样的——百度是把广告直接放到搜索结果第一名的。

第二，现在谷歌广告就剩粗体“赞助商广告”这几个字来区分了（以前是特殊背景颜色明显区分的），这几乎没法区分，离百度真是一步之遥了。

第三，谷歌中文领域的广告，那真是没法看，各种牛鬼蛇神。

不举报，那就是不能购买但已购买的可以下载（就算外区购买再切回来下载都行）。有人举报，好一点的就退款 1 年内购买的，当然国内一般都是上演直接消失术的，苹果没必要搞特例。

国内苹果市场本来也不是奔着应用商店去的，这点对苹果的市场影响极其有限，苹果想怎么处理就可以怎么处理的。

只要你做过国内的后端开发，你就会知道，那只可能是摆设。最高级别的需求也只是界面原型，数据模型从来就不属于需求或者产品的范畴。而像是数据下载这种重数据的功能，如果没有好的数据模型，那就需要人工费老大功夫去各方面抽取（难度可参见大数据 ETL ）。这功能，就是面对甲方都是能拖就拖，面对名为用户实际为产品的孙子方，能给你个摆设就不错了。

好多 V 友都反馈过了，苹果电池健康度，不是通常所说的电池容量损耗，就不要搞小心思了。苹果不一定精明，但经历过国内薅羊毛到秃手段的苹果，一定很精明。

就算按照常理，电池健康度的分母，必然也跟电池循环次数挂钩，过度充放电的手段基本只能坑自己。

产假从来就不是孤立的女权，它跟男人的权力也是息息相关的。只要是打工仔，管你是高管还是普通员工，管你是男性还是女性，给产假使绊子最终都会绊回到自己身上。

@sunny352787 #46
@snitfk #50

你们要么就是没看到本质，要么是看到了却故意忽略。所谓的岗位空缺几个月，或者一个岗位一年只能干几个月的时间，这压根就跟产假没关系，这是公司管理层决定工作计划的份内事。避开了女性产假，你能避开员工突发疾病必须住院几个月吗，这个也是跟女性怀孕一样不能辞退的。

对于产假造成的岗位空缺，实际上是有现成的解决方案的：一个活预留两个岗位即可。只要公司规划好工资构成就可达到上述方案，这对于公司的所有员工，包括管理层，都不会造成利益损失。唯一有损失的就只可能是资方，但也可能只是损失利润/时间比，不会亏本。

如果上面那边还不够理解，那么就来点直白的。假如男性陪产假跟女性产假同期，你还会找各种接口不招聘女性吗？