老游戏：《武装突袭 3 》

@g0thic 我的第一辆车是 三菱蓝瑟翼神 1.8L 手动档，销量比马自达惨多了，不过我喜欢。哈哈~~

作业任务做就做吧。积赞什么的不用理会。注册账号看视频的，大部分也是上面指派下来的任务，愿意看就仔细看看，不愿意看应付下就完事儿了。上小学之后“杂事”应该是不多了，看什么视频学什么的那种任务还是有的，比如有关禁毒或者安全知识的，这类其实还不错。现在小学低年级都没作业，小学也不让“显式”排名，总体感觉问题不大，班级微信群设置只有老师消息有通知即可。

以前的首选，就喜欢看评论，寻找认同感吧，也留了不少评论，后来版权越来越少，我一直免费听，无权吐槽，再后来搁下了很长时间，再听想评论的时候要求必须实名认证才能发表评论，我知道这是“规定”，另外确实发现搜索起来无尽的翻唱，现在唯一的用处是“听歌识曲”，找到了再在 Apple Music 里找。

事情本身不置评论，但就上下级关系或平级关系来说，我认为有胜算就较较劲，没胜算就闪人。既然你已然成为下属，如果没有其它制衡取胜资源，一走了之未尝不可，祝其他同事好运。

我自己写非常在意，看到别人不规范的我也无所谓。

还是找个靠谱的律师协助。另外，不知道现在有多少“电动车”符合“电动车”标准，应该鉴定车辆是否电动车还是机动车（没记错的话依据重量、极速等）。

在此摘录我很喜欢的鲁迅的两篇短文，同为 1925 年作品。

《立论》
我梦见自己正在小学校的讲堂上预备作文，向老师请教立论的方法。
“难！”老师从眼镜圈外斜射出眼光来，看着我，说。“我告诉你一件事——
“一家人家生了一个男孩，合家高兴透顶了。满月的时候，抱出来给客人看，大概自然是想得一点好兆头。
“一个说：‘这孩子将来要发财的。’他于是得到一番感谢。
“一个说：这孩子将来要做官的。他于是收回几句恭维。
“一个说：‘这孩子将来是要死的。’他于是得到一顿大家合力的痛打。
“说要死的必然，说富贵的许谎。但说谎的得好报，说必然的遭打。你……”
“我愿意既不说谎，也不遭打。那么，老师，我得怎么说呢？”
“那么，你得说：‘啊呀！这孩子呵！您瞧！多么……。阿唷！哈哈！ Hehe ！ He ，hehehehe ！’”
一九二五年七月八日

《聪明人和傻子和奴才》
奴才总不过是寻人诉苦。只要这样，也只能这样。有一日，他遇到一个聪明人。
“先生！”他悲哀地说，眼泪联成一线，就从眼角上直流下来。“你知道的。我所过的简直不是人的生活。吃的是一天未必有一餐，这一餐又不过是高粱皮，连猪狗都不要吃的，尚且只有一小碗……”
“这实在令人同情。”聪明人也惨然⑴说。
“可不是么！”他高兴了。“可是做工是昼夜无休息的：清早担水晚烧饭，上午跑街夜磨面，晴洗衣裳雨张伞，冬烧汽炉⑵夏打扇。半夜要煨⑶银耳⑷，侍候主人耍钱⑸；头钱⑹从来没分，有时还挨皮鞭……。”
“唉唉……”聪明人叹息着，眼圈有些发红，似乎要下泪。
“先生！我这样是敷衍不下去的。我总得另外想法子。可是什么法子呢？……”
“我想，你总会好起来……”
“是么？但愿如此。可是我对先生诉了冤苦，又得你的同情和慰安，已经舒坦得不少了。可见天理没有灭绝……”
但是，不几日，他又不平起来了，仍然寻人去诉苦。
“先生！”他流着眼泪说，“你知道的。我住的简直比猪窠还不如。主人并不将我当人；他对他的叭儿狗还要好到几万倍……”
“混帐！”那人大叫起来，使他吃惊了。那人是一个傻子。
“先生，我住的只是一间破小屋，又湿，又阴，满是臭虫，睡下去就咬得真可以。秽气⑺冲着鼻子，四面又没有一个窗……。”
“你不会要你的主人开一个窗的么？”
“这怎么行？……”
“那么，你带我去看去！”
傻子跟奴才到他屋外，动手就砸那泥墙。
“先生！你干什么？”他大惊地说。
“我给你打开一个窗洞来。”
“这不行！主人要骂的！”
“管他呢！”他仍然砸。
“人来呀！强盗在毁咱们的屋子了！快来呀！迟一点可要打出窟窿来了！……”他哭嚷着，在地上团团地打滚。
一群奴才都出来了，将傻子赶走。
听到了喊声，慢慢地最后出来的是主人。
“有强盗要来毁咱们的屋子，我首先叫喊起来，大家一同把他赶走了。”他恭敬而得胜地说。
“你不错。”主人这样夸奖他。
这一天就来了许多慰问的人，聪明人也在内。
“先生。这回因为我有功，主人夸奖了我了。你先前说我总会好起来，实在是有先见之明……。”他大有希望似的高兴地说。
“可不是么……”聪明人也代为高兴似的回答他。

前段时间看新闻有个地产商因为虚假广告被罚 2000 元。我觉得那广告值了~~

@Mystery0, feature 分支属于“私人分支”，换句话说，人在 feature 分支里玩儿出花来也没关系，它并不参与 CI 过程也不会共享代码给别人，当某个 feature 在 feature 分支完成之后会 rebase 到最新的 test 分支并压缩成唯一提交（如果 feature 分支上有多个提交的话）然后提交 PR 到 Test 分支。一旦 feature 分支合并到了 test 分支，这个 feature 分支就可以删掉了。如果那个 feature 在 test 分支上测试时出现了问题，那么基于最新 test 分支重新创建一个新 feature or bugfix 分支进行处理，并重复之前的过程。

如果出现多个 feature 需要并行共享代码联调，那么我觉得有两种方法：

1. 所有 feature 功能实现划分可能需要优化或细化，变成多阶段处理，每阶段可以无（大量）互相依赖在各自独立开发，然后下一阶段可以依赖前一阶段的代码
2. 多 feature 共享的代码部分可以交予一名主程直接在 test 分支上开发，然后其它各个 feature 分支随时 rebase test 分支。

@Mystery0, 每人一个 feature 应该是每人工作在各自的 feature branch 上吧，只有完成了当前 feature 才合并或 rebase 代码到 test branch 上，这样才可以确保 test branch 上没有未完成的代码。如果有一个 feature 依赖于另一个 feature 的代码，那么只能把这 2 个 feature 都分配给同一个人或者必须等被依赖的 feature branch 并入 test branch 之后另一个 feature branch 再从 test branch 上得到依赖的代码。

Winform 的一大问题是高分辨率下的缩放问题，会引起使用和开发的问题。比如我用高显示器 (3840 * 2160) 150%缩放在 VS 窗体设计器里 VS 提示当前缩放 150%，然后你把控件排列的好好的，然后等你在低分辨率显示器上（ 1920 * 1080 ）运行的时候就会发现控件错位甚至不见了（跑到窗体外面去了）。。。我不知道如果是 WPF 是否也有同样的问题。如果时间足够的话，还是建议用更新的技术去做，又练手，未来也有更多的拓展空间。

只能建议选新不选旧。

让我想起了当年大学买的一台 Sony CD 机，型号忘了，结果大学毕业后给了我刚上大学的表弟了。。。我甚至带着它和同学一起逛街，人家都是小小的 walkman ，就我一个圆圆的大家伙别腰上，那时候 CD 机性能标识之一就是抗多少秒的震动是吧，虽然我绝不会带着他跑步的……

OneDrive Settings 的 Notifications 区域最后一个 Checkbox: When OneDrive suggests a new collection of my photos and videos.

合适的场景用合适的工具，有些场景用存储过程、函数无论是开发难易度、执行效率、部署便利性都是极高的，毕竟数据库就是专业处理集合数据的，对集合数据的处理同等硬件条件下应用层写出花来效率也不会比数据库自己操作高，把数据库擅长的处理放在应用层，更多是牺牲效率换取可伸缩性。要说难以版本管理，确实，不过可以做一些自定义规则和工具缓解。开发不就是一个权衡么，针对特定场景，针对可维护性、执行效率、伸缩性等等一系列因素的侧重点不同，利大于弊就用，弊大于利就不用。触发器的最大的问题在于隐蔽性，属于“偷偷摸摸”就把事儿办了那种，所以这个确实慎用。

SQL Server 2016+ 有 Temporal Table ，自动维护整行历史记录，一定程度上有助于这类问题，不知道其它数据库是否有类似特性:
https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables?view=sql-server-2016