平台视角
最近出差多，不像在家里，小朋友睡觉了还要顾着点小朋友不能吵醒他。
静下心来最近好多传闻总能扰动心绪，写写文字大概能缓解下。
消息纷纷扰扰，总有人说要放开，各种奇怪的source，各种传言。虽然在物理上我们真的完全不具备条件去做这个事情，但是满天飞的传言确确实实影响了所有人的。
大概2022年的十月份看到了个对于网络空间信息污染及扭转认知的技术性文章，大概挺有意思的，也是最近这一段时间能反复相互印证的手段。
一旦有了技术性分析，事情本身可能对于我来说更多是高一个维度的观察。
主要的手段有：
1、启用冷藏多年的账号库
2、反复投放Unknown Source Speak
3、内容在普遍意义上符合一定的诉求
4、反复多账号打榜，人为攻击社交网络体系，使得本不值得讨论的问题成为了一个讨论的问题
5、一旦出现官方辟谣，一定会转为以傻子为节点的传谣
加入现在的公司应该快满两年了。贡献给公司的代码是越来越少了，大部分让我还能使用编程能力都是为了我自己的服务器。反倒是真的像车库阶段的个人电脑使用方向。工具也是初创公司才会去使用。
怎么说呢，这样分裂的感觉，又使得我更好的观察了到底所谓的技术是什么。
这两年让我锻炼出的一个基本技能就是看使用的工具链能评价出具体一个开发团队会大概需要多少开发人员，凡是声称自己公司有特别强的自我研发能力，然后发现人数队伍不匹配，大概率也就是商业吹嘘了，不会有实质性的开发能力。
出差这么多天，发现我这个新买的超薄本，性能很牛逼啊，就是内存小了点，Intel的Iris Xe能打很多以前台式才能玩的游戏了，加上20w的满血CPU，而且是稳定释放。我竟然又开始静悄悄的玩一下小时后的游戏。可惜了，我已经记不起来以前玩过的好多游戏，只能支离破碎的记得一些画面。
首先需要明确，我们调研的是什么业务。
其次应该要调研目前较为频繁的操作，必须要区分主次而不是把曾经的流程死缠烂打。边缘策略不需要太关注
最后应调研的是，不同角色的不同吐槽，然后汇总
一个有效的会议组织，应该事前分发好资料，事中做好记录，事后做好跟踪
对于傻逼议题能有效的中断。
会议必须要有时限。
一般的小公司，没必要纠结上各种高大上的分布式。耗费的成本远超当初划分的成本，老老实实用单体应用做好代码切割才是正途
另一方面，觉得这里没有技术，或者说什么叫技术：最后变成了我回归了数学。即便依旧学不懂数学。
大部分时候我们需要下属的目标与管理者的目标要一致。目标一致那么，制定计划的时候才能群策群力。
但是现在大部分时候都是，目标不那么一致，事情大概率是推动不下去的。想了很多缩减整改的方案，最终还是放弃了，费时费力还不讨好，不一定有成效。有成效也不能提升部门绩效。
大头可爱了，也闹腾了。
昨天和群里面的人聊天，谈到了别人一次成功的ERP实施
大概成功的因素有那么几个
从这些方面来看，企业的数字化转型不能仅仅是IT部门立个项目就可以了的，是需要整个公司链条配合起来，流转起来，数字化是深度嵌入在每个流程之中
Ta举了个例子
客户下订单，生产部门领取物料后生产完毕就发出去了，导致最后核算时候，多出一个产品
原因在于生产完毕后没有执行入库就发出去了
高层查账时候会很直接的导致一大批人要受罚，只有接触监管层，采取一个监管层能理解并且逻辑上自洽的流程才能修复
在这种灰不溜秋的时候是系统实施中最困难的时候
没有人员的深度参与是无法梳理出这种事项的
而这种情况下如果无法处理则ERP系统会导致所有人都不愿意使用，这个时候IT部门再强大也没有用，需求迭代是中断的
由此感叹道，一个事情的成功不仅仅是单一因素的成功，而是多个因素都成功才成功的
江说得好，既要自身的奋斗，也要看历史的进程；大概就可以从这个事情看出来
最近突然好奇到，我们熟悉的IP网络是如何运作的，查了半天资料都是说TCP/IP那几层协议，根本没有说网络是如何运行的。那我们试试头脑风暴，再发明一次网络吧
网络是由无数个可以相互连接的点组成
每个点是没有先验知识的，也就是说，点与点之间如果不是直接连接在一开始是不知道能否由通路的，但点能知道直接连通的道路
在没有点与点之间没有先验知识的前提下，我们就只能通过BFS/DFS算法来发现路径
所以当第一次通信的时候，点与点之间的时间最优情况T(n^n) （假设每个点直接连接n个点，在第二跳就能找到通路）
这个情况下，我们会发现性能是和我们现在的网络不同，应该是会很慢的
如果需要提升性能，就需要增加先验知识
点的直接通路中由特定的点具有网络通路的解释权，我们称之为高优先级点，高优先级点的位置应该预先内置在访问点处，高优先级点数量m << n
性能会提升至T(m^m)
假设我们可以广播，亦即是发出一个信号，如果点能到达，则返回路径表，此时的实际访问次数是T(h) h是网络中的最先达成通路的深度
在未达成通路之前，整个网络相当于开启了m^m^h个半连接，会产生信息风暴
划分网络，减少同时建立的半连接数量
这个时候是不是就有点像我们的现有的IP网络了
硬件层就是能直接连接的路径
需要中间转发的，就在IP协议层完成
比如ICMP就是我们的广播信号
在一些核心交换机上还存在手工配置的路由表，就是高优先级点的先验信息
网关就是我们的高优先级点
划分就是我们的掩码
当然这都是我瞎几把想的东西，和实际出入应该大了去了，IP网发展了这么多年，基本模型都有可能变了
电动车好
命题：电动车是续航短
定义电动车：以电能作为最终使用的能量形态的汽车
定义续航短：续航少于300公里
命题：电动车是不能跑长途的汽车
定义不能跑长途的汽车：在路途中允许补充燃料并能够将人从出发地顺利的移动到目的地的车辆
命题：汽油车三五年后残值是高于电动车
定义残值：经过了三五年的使用后的物件市场再次出手的平均价格
电动车在续航超过了300公里以后，可以单次从一座城市到达另一座城市。从这个场景续航是满足的
这个问题的延续就是不能跑长途
无论是什么能源的车最终其燃料都是有限的，需要从外部补充，那么从补充上的便利性，燃油车确实好于电动车在目前（2018）的时间节点上
但是该问题的核心在于能够便捷的补充燃料，对比电的运输与汽油的运输，在其他维护和设备价格相同的情况下，则电的运输是优于汽油的运输
汽车的残值是与使用者保养有关，不能直接挂钩，即使汽油车，使劲用甚至其价格会低于均价（不要认为均价就是你能成功脱手的价格）。另，目前电动车残值不高的原因在于，电池的发展过快，无可获利的电池回收业务，电池占车成本的比重较高
待新的回收技术或者其他技术出现后该问题自然解决
以上提及的问题在三年内都有望得到解决，这些均是在车辆正常寿命未到前能够达到
在当前时间节点上，因为有国家的补贴情况下，购买电动车，并不是一个更坏的选择，尤其在大型城市在较难获取路权的情况下，政策倾斜更应该是优选
做起开发发现浑身不对劲就很难受了
需求变本来就是常态，为什么品控部门必须要有确定的文档才能进行需求开发
难道开发面对变更，测试就不需要面对变更吗？
测试参与到开发来，而不应该是测试只管根据文档测试其他都不用管
目标难道不是交付合格的软件么，没有写好的文档就不能交付了么，无非就是撕逼的时候为了个责任划分而吵吵吵吗
一点都感受不到大家是为了交付或者是有共同的目标，就单纯的是为了工作而工作，能做出什么像样的东西么
还有，需求日期这种东西，不应该是开发人员预估个时间，然后才能是对外宣传的呢，怎么能说是随口说出去，然后层层下压呢
最少也应该在开发给出一个不算太靠谱的时间之后进行压缩吧
一个稳定的软件不应该是要留足开发空间么，而非只是为了收钱而交付啊
就算是为了满足生存的需求，那生存本身不应该是压缩成本吗？没有做好亏一段时间的准备，难道创业是不需要成本的？
这些看起来不像是问题而像是控诉的话题，应该就是所谓的问题了吧
这些问题问了自己好久，得不到答案