2025-10-28 00:00:00
程序员总会遇到这样的问题，走技术道路还是管理道路？以前也有亲戚或者爸妈同事的孩子（计算机出身）想问问我以后的路要怎么走，以我个人经历来谈一谈
接触程序比较早，属于是初三、高一的时候就已经在写程序了，只是那会是玩按键精灵，VB语法，大漠插件，那会觉得会一个语言好厉害，C++好牛，C、C++、VB都学了，写点我自己想要的自动化程序已经是没啥难度的了。
在那个年代，搜索引擎还是很好用的，想要啥就能搜到啥，没有那么多废话。但是在外挂这个偏门领域，想要再进一步有点困难了，当年感觉Windows的Hook简直就是天神下凡，有啥你想要，但是现有的库或者接口做不到的，Hook都可以做到，各种奇巧淫记。但是这东西只是偏门，而且用起来恶心，很多东西没有明文说明，都是摸索出来的经验，现在想想那会还真是糊里糊涂的在写代码，拿着一堆没搞明白干啥用的东西，底层逻辑也不清晰的就糊上去了。
至于当时的面向对象、面向过程，对象是没搞明白，但是过程可太熟悉了，做了无数个过程代码，多少算是锻炼了年少时的逻辑思维能力吧。当年的计算机二级，辅导过各种大学生，想来也挺搞笑的，初中生辅导大学生。
高中时第一次知道了物联网，感觉这个概念可太牛了，那会大概是10、11年，那会估计物联网专业的都不知道他们的物联网能干啥，那会我已经自己想通了电视、冰箱、洗衣机等等家电联网的逻辑，想想那会可真是领先了一大批人。
大学专业也毫不犹豫的选了和计算机相关的专业，以我当时的自信吊打一下大二大三应该也不是问题，计算机的课大部分不上我也知道咋回事，课本都自己看，自己学了。老师讲的不一定有用，但是我自己看过的内容后来都被我用上了，很多我能发现或者意识到的问题，都是基于过往的积累，如果当时没有看过，工作的时候就完全不会想起来这个内容
但是也有一个方面发现落后了别人好多，校内的算法比赛，第一次看到题懵逼了，这是啥？后来比完看到差距以后，才明白别人从高中就开始在信息竞赛里天天训练的脑子还是真牛，自此以后再也没参加过算法相关比赛了。
刚开始还记得初心是做物联网，买了些开发板，学习了嵌入式相关的知识，学完以后觉得可牛逼了，没啥智能家居我做不出来了，那会也确实如此，很多智能家居的东西还是非常简单的，看一眼就知道用啥模块可以实现了，但是对于整个物联网生态还缺少体系化的思考，也没意识到这个东西后续是个万亿级别的市场，在当年还是非常有机会的。
后来参加电赛，接触到四旋翼，从那会开始就走偏了，忘记了物联网的初心，去搞飞机相关的内容了，当年四旋翼也没多少人搞，很多东西都没有，那会也不太会翻墙，少了一整个Google和GitHub，那会已经可以组起来一个较大的嵌入式工程了，软硬都了解，想做啥基本都可以做了。
同时也走了一些弯路，当时弄了一些Window phone的C#开发，后续这个东西停了，就废了，Web那会还不认识Spring，傻傻的拿Html写前端，真的有点坑到当年的队友了。
学生时代技术已经十分发散了，C为主，C#、C++为辅，后来又自学了python，基本上主力语言都摸了一遍，不看语法，大部分语言都能直接看懂了，接触过的技术栈也非常杂：嵌入式、.NetFramework、MFC、HTML、Windows Phone、Unity3D、Latex
好在那会补全了我的一些知识体系，至少从底层、编译、操作系统、应用、UI，由下到上这么一系列东西让我体验过了一遍。大三后期又上了很多软件工程的课（当年上的时候已经被淘汰了），但是作为一个工程学，他的核心思想竟然后续都被我吸收了，这是我没想到的，也没想到这个简单的工程思想竟然在实际工作中遇不到有人会，真的挺离谱的，软件工程也成为了我后续发展的主要考虑对象
等到了工作时，算是对我自己的专业知识、以前漏掉的一些知识内容重新查漏补缺，再次巩固我自己的专业度，深究每一段代码的含义，彻底拿下一方面的技术。在这个基础上，又往其他方向扩展了一下，算法方面，多年没有深究，再次接触，系统学习了一些算法知识（本质上是数学，图论），捡起来以前离散数学，发现很多问题迎刃而解了，有了更优的解，解了很多实际中的问题。
在唱衰互联网的时候，又学习了一下Springboot整个前后端相关的知识内容，又做了一个实际项目，对于整个网络端业务体系，算是有了一个深入了解，后续再做联网相关内容的时候就能考虑的更完善了，不再对我是黑盒了。
到这里基本上我算是从底层到上层，整条数据链路都打通了，技术栈相对完整了，所有内容我一个人都能做了
纯语言、纯某个技术栈，有上限吗？有，也没有，要挖深，可以无限往下弄，但是工作、业务真的需要吗？普通人有可能涉及物理或者数学的理论基础吗？不行的，多数情况下，你所做的业务能完成工程化就已经非常好了，足以吊打很多野路子了。
当纯技术我发现没有更多突破的时候，我开始转向技术的周边，比如整个编译架构，CI/CD，比如整个工程从需求到落地需要经历的每一个环节是不是还能做得更好，自动化，工程迭代能否用更少的人力，更小的改动，达成更大的目的？整体架构对于业务支撑是否拥有足够的包容度和扩展性，能否轻松改几行代码或者复制粘贴几个文件就能达成一个新硬件支持？我开始深究从第一行代码到业务覆盖，是否能给出一套方法论或者工程指导，让我或者其他人达成一个高效的迭代开发体系。这些想法我都先用在了我自己的代码、工程中，我自己验证每一步是否可行，是否高效，当我验证完，就把这一套推广给其他人了，大家使用一套类似的方法论，甚至可以对此进行二次优化，逐步做得更好。
从技术转向工程，算是完成了第一次转型。
然而每个人的精力是有限的，我总不能什么都管，有了工程体系，我就可以考虑逐步把手上的技术交给其他人去做，只要工程体系没有大问题，那么随着需求迭代开发就没问题。
手上技术拿的越多，技术越广，最后都要面临把一个个单项技术分出去，分的越多，最后手上剩下的越少？就约专注？好像也不是。刚开始是不断捡起，但是随着东西越来越多，开始学会放下，学会交付给别人，否则一定是分身乏术的。而随着手上的东西越来越少，也就有时间去思考超过技术、工程本身的东西，从更高的角度去看问题，去审视每个人所在的位置，每次遇到的问题根源是什么，此时开始偏向管理，工程转向管理，第二次转型。
纯技术工作对于我已经没有挑战了，转型管理也是必然，管理本质上还是为了业务和人员服务，如何让大家更好的工作、业务更好的开展罢了。
当然并不是每个人都要这么做，每个技术都有各自所在业务的深度，有的技术是需要不断突破，不断创新的，这种持续做技术完全没问题。而有的技术，当你做到一定程度，可以拿下整个技术栈的时候，你是选择躺平了呢，还是继续寻找突破点？因人而异吧
技术本身与业务是不分家的，如果纯纯只做技术，不了解业务，只能说你技术肯定做的不行，好的技术一定是非常了解业务的。当技术搞定时，此时还有一个角度可以玩，那就是去做业务：产品经理，这种类型的产品拥有无与伦比的优势，天生了解技术细节，能跳出技术本身，看到业务的矛盾点和方向，可以让产品发展得更好，让需求少反复几次，让技术实现少走弯路。
我在做管理的同时就发现了，很多问题可能不是技术的问题，不是工程的问题，他可能是产品的问题，整个产品的定义或者细节中漏了一些东西，甚至产品本身就是定义不全的，而这些东西对于落地非常关键，一旦被模糊了，那么就会导致落地时有问题，在落地阶段反复修改之前的功能或者定义，与之对应的，我又做了第三次转型，同时兼管产品，确保产品实现的效果是我想要的，每个细节都有具体的定义，不再模糊放过问题，这些都会导致后期再进行维护时带来很多其他问题
以前觉得别人说代码设计，要瞻前顾后，写个类，写那么多冗余、抽象的东西，毫无意义。但是今天当你站在实际业务前，看到业务里各种前后兼容的丑陋设计时，就会感觉到，前期留下的冗余代码在此时是多么的细节，但是这种能力不是每个人在当时都能看到，都能做到的，只能说在后期一次次重构的时候会多想一想业务，把代码平台本身的扩展性设计得更大，代码包容性更强，那么业务的变动都在代码考虑之内就毫无难度。
对业务不够了解，不应该去做重构或者是创新，这样的玩法只会浪费时间，凭空做了很多没有价值的创新和重构，特别是新人刚加入项目。
做协议，必须对上下层都懂，否则只会以偏概全，最后做出来的结果别人不愿意用，最后不了了之
培养一个资深测试，特别是对于业务无比了解的测试，价值远大于一个产品和技术
不要让拿不下业务的产品进行需求开发，只会把产品带偏
超过半小时的会议，会议内容一定过于发散了，要尽量缩短会议时间，快速沟通矛盾点，没问题的地方直接跳过，不要废话
以自己当前的经验，总结一套方法论，其实就是对于业务开发的方法论，希望新人也好，还是有经验的人也好，可以从这里学习，知道自己在什么位置，应该做什么，有经验的人可以帮助完善这一整套体系。
以目前我的角度来看，无论大、小公司都有一套自己的方法论，这套方法论被反复在内部的产品上验证，它可能不是100%会成功，但是成功的概率是远大于一帮乌合之众的凑到一起做出来的。
从我的角度，不一定要模仿谁的方法论，每个公司或者项目都可以走出自己的路，很多东西是要结合当下的情况来定的，很多别人的经验没办法直接搬过来用，更多的是借鉴学习别人的解决问题或者矛盾的方式方法，并不是抛弃自己来时路，抛弃自己曾经用过的方法。
一些粗浅的想法
2025-10-09 00:00:00
据说十一开始的前后两天，路上都非常堵，那我只能等到人不多的时候，开始自驾，逛一下广东周边，时间还是有点紧张，边走边记
粤东大致路线
本来想去曾师傅-宋·川菜珠江新城店，但是曾师傅的双人一饭封神体验餐十一不能用，只能现场点菜，这就比较麻烦了
后来还是先去了客·AKEN’S KITCHEN 私房菜，398￥一个人，一共大概是九个菜
感觉一般，没有什么说是特别好吃的，吃完大概七分饱的样子，工艺属性拉满，仪式感高一点，其他的一般般吧。
还是推荐去吃大厨的，这种小厨、私房的东西还是有点拉了，和米其林的服务比起来还是差了一些
距离广州老远了，这也能算广州，我有点没想到
一去别人村里在摆宴，看了下刚好是今天10.3，还没开始，结婚的是两个姓陈的，而旁边就是陈氏祠堂，大户人家。
而里面的古村早就没人住了，能进去的就两间，全是马克思
古村里除了我以外一个游客都没有，一个都没有，甚至连工作人员都没有，这个地方真的是坑爹。
古村后面还有个小山，也是很久没人来了，我随便逛了下，糊了一脸蜘蛛网
邓山村也是非常偏，但他也是广州的，以为真的是个观星小镇，其实啥的没有，连个充电桩都是坏的。
古榄园，唯一一个能勉强算得上景点的地方，同样缺乏维护，更像是村里的村景，不大，一眼望得到头，十五分钟就能走一个来回了。
邓山村的路上，有一个小水坝，有不少家长带孩子来玩水，也有搭帐篷、露营的
以前可能是真的老街，卖一些老东西、特产什么的，各种鱼干啥的，但是现在这个街翻修了，变成了仿古建筑了，狗屎一坨，然后这个街的石板路没铺平，高高低低的，走起来很别扭，很多商铺都还没人，没装修好。
不值得去，卖的那些东西，广东基本都能买得到，晚上住在这里的民宿，垃圾的一批。
老街附近的正果寺，没啥好看的，但是寺里这个桌上，放了个小乌龟，真的超级有才，特别是后面的院子里标着狗粮、乌龟粮，配合这个小茶桌上的小乌龟，别有一番风味。
难评，也是河边的沙滩，晒得要死，有人租遮阳棚，河边本身是禁止游泳的，但是依然开放了这里，缺少救生员，都是家长带孩子来玩水、玩泥巴的
开车一个多小时，下了高速以后基本就到了，但是发现1.3km的路堵1小时以上，那不用想了，不是里面爆满了，就是路上出事了。趁我还没进去，直接掉头走人。
溪头村是有可能是那种可以溯溪玩的，可惜了，看起来可能和前面去的邓山村类似，都是一下高速，走一段就到景区了，估计也是个村景。
之前广州公众号里推的小镇，南平静休小镇、西和小镇、米埗小镇、生态设计小镇、吕田小镇、莲麻小镇，实话实话说都是只能观赏15分钟就得走的地方，但是距离一个赛一个远，基本距离广州市区都是1-2小时车程的
好久没有走过村里的国道了，有的是真的修的不错，肉眼可见的好，有的是直接就在修的，很难走，还有就是那种大小补丁的路，一颠一颠的。
国道路过的大大小小的村落，其实都很偏，但是国道把这些小村子都串起来了。
门票很便宜，34，云髻山不算特别高，走慢一点，大概45分钟-1小时就能登顶了，中间大概会路过三个瀑布，还行
总的来说勉勉强强吧，算是比其他几个地方好一点点，但是总体景区的指引缺少，卖水的都很少，全都是卖豆花、糖水什么的，很奇怪。山路台阶不太好走，高的老高了，窄的的又特别窄，放不下脚的那种。
人不算特别多，停车到景区山脚下就行。
时间太紧了，这个地方本来打算去的，但是看下下，这地方光是走路就得2小时起步，就算有电梯辅助，也少不了多少。
晚上去梅州路上第一次遇到高速堵车，大概是几个货车撞了，一个翻车，几个追尾，堵了一个半小时一动不动的那种。
叶剑英纪念馆、千佛塔、泮坑瀑布就不去了，红色、佛教没兴趣，瀑布由于要去黄满磜，这里就不去了，但是听说也不错的。
客家博物馆附近是有点堵的，停车不容易，建议稍微开过一点，路边有很多停车的地方。
客家博物馆广场挺大的，但是没啥内容，空大，人都挤到博物馆内了，主要是客家起源、发展，大概了解一下。
值得吐槽的就是客家的冰箱贴可真贵啊，随便一个就二三十，重庆可是五块2个啊，这个价格有点离谱了，广东都这么有钱的嘛？
江北老街，有点以前去厦门的那种风情街的意思，看起来都是新改造出来的，卖的自然也是游客价，略贵。
走出老街以后，吃了个掩面，确实挺便宜的，但是好像没我以前深圳吃的便宜，好像烧卖也是这里的特产？很多烧卖店，就是卖相有点难看了。
雁南飞茶田景区包含两个，一个是茶田，一个是桥溪村，进去要做巴士，当然你也可以纯走进去，稍微远了点，建议能坐都坐，里面还有的你走呢。
茶田类似梯田一样，可以拍照打卡，其余的景色都一般般，只能说有，没啥玩乐的，纯逛。
桥溪村需要做巴士走盘山路，会路过一个大水坝，但是也只能远观，上去以后就是村口了
桥溪村应该是最拉的，服务人员还说限制时间，但是实际上地图所有标注的xx堂、xx楼全是别人家，你只能看看外表面，那里就是本地人自己住的房子，没有任何特殊的点，就纯骗，过来的人都有点不明所以。
然后桥溪就有个小溪一样的，有些位置可以给你稍微玩下水，再就是栈道，栈道尽头是养心谷（三个大字）没了，对没了，你还得原路返回，旁边你也能爬山，不高。
只能说这个景点有点点离谱，适合拍照，如果人多可以租一个接驳车，大概可以坐七八个人，然后在景区内逛比较方便，其他的就真的一般般了。
揭阳的路是真的搓，车道线不明显，全磨没了，晚上根本看不见，大家都随便走，然后路上各种鼓大包，我悬架弄到最高我感觉都有点刮底盘。
有点孔庙的意思，带小孩逛逛还行，其他的就一般般吧，围绕整个学宫，弄了个揭阳古城，周边是些吃喝玩乐的地方
行程中止，后续的行程只能下次再说了
万万没想到，离开揭阳前，从停车场出来，就撞上了这个石墩子，然后爆胎，右前铲又被干爆了。这个石墩子在车内360完全看不到，由于又是刚出停车场门口，本来近距离报警就一直响，就没注意，加上他这个本身就有个台阶还是个坡，能走的路就一点点，停车场出来不能直行（石墩子刚好档在了右侧），得先左打才能转出来。这个石墩子对比其他墩子都被蹭的黢黑，坑了不少人。
回看视频，行驶速度就5km每小时，但是就是干爆了轮胎，有点奇怪，车胎爆了以后，车机立马就提示了，然后就是小米道路救援，看本地是否能维修或者处理。以我上次的经验，这个前铲刮了、然后前保险杆有点翘皮了、轮胎爆了，必然要走报销，而且一两天都弄不完。
协商了半天，揭阳本地修不了ultra，也没备件，最近只有汕头才行，但是行程就剩2天，咋都弄不完，那就拖回深圳处理。正常小米道路救援只能拖回邻近的城市，但是十一期间加上ultra会员，可以直接拖回用车城市，免费。
由于爆胎了，客服又说最好别移动了，会导致轮毂受损，失圆，换轮毂又是一笔不小的费用，但是我停在了停车场出口上，还好这个停车场是双出入口，我堵了一个，还有另一个，停车场的老哥直接立了个牌子让他们绕去那边，不然一直有车bb，谁也顶不住。
但是等拖车等了接近4个小时，从11点多等到16点，拖车才来。来了以后，小米流程很复杂，这也要拍照，那也要拍照，把拖车司机折磨疯了，等拖的时候拖车要横过来，卡住整个马路，然后发现拖不上去，会直接刮底，刮前铲，就只能重新协商，要我本人同意，自己开上拖车，失圆责任重新甩给我，无奈，所有人都等了一个多小时，只能接受，重新开上拖车，大概就10m，就能闻到右轮的焦皮味。
当晚我到家以后，车也同时到了小米售后中心，但是这个卸车没有接车人，司机直接把车卸路中间，人走了，不知道这该怪谁， 小米愿意提供服务，但是中间环节又有漏洞，难顶。
小米客服说是上了拖车以后就会发放打车券，500，我被重复发了，给了1000
可是打不到车，揭阳回深圳太难了，加价到一千，都没人接单，而这个打车券是高德的，只能打车，不能顺风车、也不能拼车，很无奈了，而且还有时限，也暂时用不上，浪费了
揭阳到深圳的高铁是一张票都没有啊，十一还是太恐怖了
于是乎只能滴滴打顺风车了，顺风车倒是不贵，独享也就430多，但是体验真的是一言难尽，怪不得那么多人喷顺风车，真的不是没道理。
顺风车一共打了六次，最后一次才真的上车，基本上前五个，每个都要私下加价，是直言不讳的说要加钱，一问加多少，加300，车费就430多，加300？你是真的敢叫，且不说还是些烂车。实际从揭阳到深圳大概300多公里，算上堵车最多是5小时，如果车费700多，算算时薪100+，这些司机是一个比一个黑。
最后一个打到的顺风车，算是比较好的体验了。
最后一个司机也是职业顺风车司机，但是不是坑人的那种，大家聊了一路，大概了解了一下顺风车的内幕。前面不走的这种司机，不但加你价格，还要中途带人，一趟下来必须得盆满钵满才行。由于我是独享，那就更不愿意带你了，而你要是拼车，那算是完了，厉害的人家开2小时都出不了本市，贼离谱，一定要把拼车拼满才能走，时刻要保证车上满载，否则就得各种拼人，真的离谱。然后平台也默认拼车人的时间是没有上限的，你今天一天都耗到车上也完全没问题，这就导致了看似便宜的拼车，实际时间成本无限高。
平台本身在整个行进中是不允许司机和乘客同时关闭APP（杀后台）的，一旦同时关闭了，立马就有人工电话打进来询问情况，要求你和司机同时开启，这个也挺合理的，确实能保证安全。
行进过程中，如果司机开太久了（3小时），会强制要求司机休息（20分钟），否则之后就不给司机派单，直接拿捏你司机。
司机开的乐道L60，开顺风车的时候，直接智驾，其实3小时疲劳根本用不上，如果你不赶时间的话，智驾高速上驾驶比你自己稳多了。
从揭阳去深圳，路上基本走沈海高速，但是沈海是真的堵啊，整个高速大概就有三四个堵车点，其中两个一个堵车14公里，一个堵车11公里，不绕，今晚就高速上过了。
司机和我一人一个导航，我百度，他高德，互补导航，我们各种在堵车前下高速，走过拥堵以后再上高速，这么来回走了2趟，总算是走过了所有拥堵路段，一路上就能看到很多类似的绕路车辆，基本都是粤A、粤B的。比较符合导航刻板印象的是，在一个红绿灯，所有高德导航都往左走去了乡间小道，而所有百度都直行走了国道或者省道。
乡间小单单行道，但是距离近，直接横穿了，但是晚上很多车，很多村里摩托，行车压力还是大一些的。
国道省道，那就是两车道或者三车道起步了，路宽也亮，摩托也少，就是绕路有点远。
而在路上，小米车主果然都是最符合刻板印象的车主，一路超车，单行道也要找机会各种超
最后走了接近5个半小时，中间停车充电了不到20分钟吧，总算回到了深圳。
整体也算是挺有意思的一趟，上次坐顺风车可能还是五年前了，大晚上走了好多村子，确实看到了好多以前没见过的。
广东的村子有的富有的穷，但是总体村里的道路都算不错的，有钱的村子，路边的家家户户都有灯带装饰，路灯上挂着灯笼，可能本地人看多了不觉得有啥，但是外地人光是路过就会觉得哎这个村子不错，然后晚上各处都在放烟花庆祝中秋，穷一些的村子就没这些了，有条路就不错了。
实际开了三天吧，走了935公里，基本能智驾就智驾，80%都是智驾开的，我只负责上下高速和城区或者村里。
长途驾驶或者堵车，基本都是很轻松的，高速上只要不乱搞，你不会主动发生事故，大部分情况也都能应付得过来，开车反倒变成了一种休息，景区里逛累了，开车去下个景点的时候休息一下，如此反复，还挺好的。
没升级到端到端之前，普通的NOA，还是挺好用的，130定速巡航，大弯都能稳稳的过，但是后面升级到了HAD就不行了，大弯会突然要接管，吓死个人。
然后城区使用HAD，开车决策还是过于肉了，超车变道也很慢，每次判断之前一定都会减速，然后后面跟的车，就会闪你或者b你，影响你的智驾使用体验。
如果没有其他车干扰，那这个东西确实能用，确实你可以不接管，完全给车自己开，但是现实情况人会受到外界其他车主的影响，而且行驶过程中遇到人行道、路口、红绿灯等等完全没有阻碍的情况下，他也会默认减速，就导致乘坐体验不太爽。
智驾过程中也遇到了极端天气的情况，超大暴雨，一瞬间就啥都看不到了，智驾会提示接管。但是如果是不那么极端，比如前后摄像头人眼已经不太能看清了（有水雾、脏东西等）似乎也能正常智驾，不会提示遮挡或者接管，不知道是靠什么实现的
以下行程就以后有机会再说吧，节假日就不乱跑了，真的太堵了，广东是真的人多车多，还是有钱惹的祸啊
汕头，早茶
感觉自驾还是得多带一个人，可以帮忙看看导航，提前规划路线，能省好多事，说不定我也能不撞石墩子了呢？
https://mp.weixin.qq.com/s/l5U26QKp87wbi4HKJAm23A
https://www.v2ex.com/t/803573
https://post.smzdm.com/p/688340/
2025-09-30 00:00:00
七月份去的河源，太忙了，一直没空记录
总体河源还是个小县城的样子，去河源的路有点难顶，高速一直在修，路上限速80，车还挺多，很多大车靠左走，非常离谱
万绿湖的云都特别好看
万绿湖内的民宿，可以看清整个景区，其实不大。万绿湖游玩主要是做游船去湖里的各个岛上去逛
万绿湖名义上是广东水库，所以一般是不允许你下去游泳什么的，但是由于万绿湖特别大，所以很多沿湖的边上，有一些缺口，就有人过去露营、游泳，玩水什么的。
有一说一，正好是雨季，晚霞特别好看
万绿湖附近都是以吃鱼为主的餐厅，感觉一般，客家菜很多，待了几天，每天桌上都有一个客家豆腐，吃吐了。
曾经的亚洲第一高喷泉位于河源大桥与珠河大桥之间的新丰江中心，每到夜晚时分，喷泉水型多样，变幻莫测，融声光水色于一体，十分壮观。喷泉表演一般在晚上八点左右开始，持续约半小时，在欢快愉悦的乐曲中，绚丽多彩的喷泉水柱随着音乐舞动，气势如虹。不论是专程前往，还是沿着新丰江漫步经过时，这里都值得去看看。
据说喷泉高度有190米，估计现在应该没这么高了，这玩意都20多年了，喷泉配合的广播、音乐还是20世纪的味道，这二十来年估计一点都没变，只能说20年前这里是真有钱啊
喷泉一共大概持续25分钟，前面就是各种循环没啥特殊的，就最后1分钟才喷最高高度，也就那么回事。
晚上很多老人、妇女，领着、抱着小孩来散步，隔江看，喷泉跟前停车可真的老困难了，江边的停车位都是满的，技术不行进都进不去，别说停了
车停在河源市政府，晚上市政府停车位很空，里面的不知道是保安还是啥，直接招手让我们进去，说免费停，还挺好的。
从市政府走过去，电视塔下的就是茶山公园，就是一些普通的街健的器具，有一些摆摊的老人，人不算特别多。
茶山公园有几个奇奇怪怪的罗马柱，风格不太搭，旁边的公测还在改造，但是造型是个大桔子
电视塔一直播着各种广告，在城里挺显眼的
番外，河源机动车审批很离谱，各种按道理上不了路的车，在河源都能上，很多稀奇古怪的车，可能挂的都是河源的牌，粤P开头
2025-09-25 00:00:00
从建立这个博客开始，到现在（2025.9.25），已经快10年了，最近一看访问量有一百万了
Blog经过多次修整，目前相对比较稳定了，能满足我自己用，也不太需要二次开发
2015.11.1 上线
2017.1.9
2018.2.9
2021.4.28
Hux长期不更新，Hux用的js的cdn基本国内都挂了（导致网页加载时间极长），所以将部分link转成bootcdn部分直接作为本地文件存储了
修改代码中注释的渲染方式，看起来更明显了(之前的灰色斜体中文简直不是给人看的)
删除了一些没啥用的文件
移除Hux残留的一些编译文件
移除代码中早已过期的注释的内容
2021.4.30
2022.2.23
2022.12.14
2023.2.4
2023.3.25
2023.4.10
2023.7.17
2023.12.12
2025.11.1，Blog在线十周年
最初的blog用的域名是elmagnifico.me，用了一年多，后来才换成了elmagnifico.tech
22年底，基本23年才算是接入了统计数据，之前的PV、UV一直没有统计，就估计了一个值，加上去做偏移了
site_pv_num = parseInt(site_pv,10) + 572573;
site_uv_num = parseInt(site_uv,10) + 490731;
接入统计以后，3年大概就有40-50w的pv了
感谢Github，小Blog托管10年，接口都没变过，即使被DDOS，也没掉过线
Blog早年搬迁到自己的服务器了，但是Github pages一直在备份，从没出过问题
坚持写了十年，好多我自己关注的博主都断更或者变年更了，Blog从一开始的记录，变成了现在我自己的小众知识库，接触的东西越来越多，没办法记住所有的内容，不如写出Blog，需要的时候来翻一翻，本来定的目标是每周至少写一篇，后来发现一个月能发四篇就不错了，再到现在可能一个月能写一两个文章，想不起来要写啥主题了
2025-09-18 00:00:00
之前写了Plane的基础指南，但是用了这么久以后，发现当时的理解还是有一些偏差，这里再补充一下Plane的最佳实践
https://github.com/makeplane/plane
Plane开源的项目管理工具，目前还是非常好用的，而且没有开源版本目前还没有做出来为了商业版做各种恶心人阉割的操作，目前还是值得推荐的
最近Plane的版本号从0.28直升到了1.0，意味着他认为他多数功能已经做完了，只是这个1.0版本到底更新了啥内容没有详细介绍，目前更新日志还对不上。
Plane也接入各种语言，目前中文也可以使用了，虽然还有一点点没翻译到位
还是以团队形式来说，如果只是小团队，每个人可能都身兼多职，没有生产等环节，单纯软件开发，那么这个工具按照我之前的流程使用基本就够了。
但是如果团队规模比较大，涉及到实际生产，那么可能之前介绍的用法就有一些过于简单了。
以下都是基于社区版的Plane进行的项目管理，社区版本缺少了任务流转、模板、细化权限等内容（商业版有），但是用下面的方式可以一定程度上人为补全缺少的功能。
下面的实践都是基于一个小项目组，比如10人以内，超过10人以后就应该再拆分一个项目组，对于整个项目来说可能还得有各组之间对齐的项目面板。
如果只是敏捷开发，那么只需要在整个workspace做好工作规划即可，然后把规划后的内容逐步放入每个周期中，周期排的够多以后，每个周期都有一定的工作范围、实现目标，那么基本上整个项目规划自然而然就串起来了
整个项目的完成时间或者节点就可以通过周期视图来看出来了，只不过Plane的这个周期稍微有点不适合而已。
对应的就可以用Plane中的module模块或者Label来把各个模块打上标记，从而通过筛选后看到各个阶段完成的目标是什么。
到这里只是规定好了Plane每个部分怎么用，但是具体到每个人他应该怎么用Plane，哪些事情应该由他来做，哪些事情应该由别人来做，其实很多时候就是这个没定义清楚，导致大家不知道什么是他要做，什么是别人要做的，就会觉得这个东西有点难用了
在开始之前，还需要完善一下Plane中工作项的状态
先设定一个团队组成:
首先是产品经理做好需求和规划，将这个部分全部建立对应的工作项，如果长期需求还没写好，那可以先把近期内的都先建好，任务状态是需求完善。
第二步研发负责人将需求进行分解，拆解成n个研发的任务，这部分任务就自然的建在需求的下面，作为子项，任务状态是待做
第三步测试负责人提出测试计划，测试用例，可能还有对应的自动化测试的任务，也是作为子项，任务状态是待做
完成以后类似此图，依此类推，就可以建立出来n个产品需求
第四步需要所有人一起核对排期，任务时间，确定这个需求总时间大概是多，比如七天或者八天，近期打算做的任务都需要这样大概排期一下。
第五步产品将需求排入周期中
第六步周期正式开始了，此时研发开始填他各自的任务，时间，将每阶段完成情况回复到任务内，同理测试，任务状态是开发中或者是测试中
第七步开发基本完成，测试需要额外建立出来一个测试bug，并且一一指定到对应研发，任务状态是开发中或者是测试中
第八步，产品确认是否需求一一完成，符合预期，任务状态是完成或者是延期完成
到这里基本一个小循环、小周期就完成了，后续基本按照这个模式继续往下走就行了。
上面说完了纯软的，但是到软硬都有的制造业，这里又有很多不一样的东西，导致上面的流程不足了，需要额外再利用起来Plane中的模块和视图内容
这里借一张图，制造业的时候，就不止一两个团队在项目中了，光是研发中就有5个团队介入了，这个时候Plane要怎么管理才能显得不乱呢。
研发过程类似上述的敏捷开发，这里不再重提，主要是说一下，在整个项目过程中各种职能的人要关注的内容如何用Plane实现
项目经理需要关注各个阶段的内容，各个项目组是否按照预期完成了
所以项目经理需要建立几个大的模块，这个模块就按照项目阶段来分，比如EVT、DVT、PVT、MP
具体的任务就需要项目经理和各个项目的负责人（产品/研发）确认这个内容属于哪个模块
后续项目经理就要关注各个阶段的任务是否有完成，要协调各个组的事宜。
研发这个部分就比较简单，按照敏捷开发流程来就行了
此测试非各个小项目组内的测试，这个是做可靠性、产品方案验证等内容的测试，是对批量的测试，而不是简单单体级别的测试了
测试在这个过程中也依赖研发的支持，有些内容需要先开发完成才能进行测试，这个过程也需要项目经理进行协调、统筹
可靠性测试的内容，报告需要上传进Plane，Plane需要放开附件上传大小的限制，否则很多报告不够
到了生产阶段，基本前面的流程都跑完了，这里关注的就是研发交接给生产的内容是否ok，生产发现的问题的追踪，改版改款的变更等内容了
每个生产批次也一样可以建立一个模块，具体的变更或者交接内容都存放在这里即可
当批量出货或者在各个阶段的时候，出现质量问题时，质量就需要单独建立自己的质量追踪面板
在量产过程中发生的各种问题，质量就可以通过质量追踪面板去管理或者查看各个任务的情况
Plane目前是这么玩的，可能有一些理想化，要把整个项目组的人都协调进去，教会他们使用Plane需要花一些时间，跑几次流程以后大家熟悉了，走起来就顺了。
Plane的商业化进度真的是挺慢的，甚至我写的插件和我们开放出来的Plane，Plane销售都认为我实在二次销售免费版Plane，有点搞笑了。
Plane取消了本地部署的商业版本，只保留在线版本，有点可惜了，很多商业环境是不允许使用你这种在线的版本的，更何况你的服务器还在国外，Plane销售甚至还想拉我做中国区代理，让我给拒了。
Plane的商业化实际还是会走向Jira等软件的老路，从简洁变复杂，最终年轻的勇者也会成为巨龙，再等下一个勇者。Plane目前看起来距离飞书的项目管理还有不小的差距，目前只能是赢在免费，轻量，大家用起来简单而已。
2025-09-11 00:00:00
ARP相关的问题进行测试或者找问题的时候可真麻烦，很容易受到习以为常的一些操作的干扰，导致无法发现真实的原因
设备不上线的问题太多了，各种各样的，还都是偶发，没有现场，无法复现，针对这个问题造成的情景很多，下面 一一列举：
以上问题大部分情况下基本都是同一个东西造成，mac表错误，设备发送的包全都被丢弃了，要理解这个问题需要知道下面的机制
以下机制都经过了验证，确实会出现ARP广播
二层局域网中，如果设备之间通信不仅仅需要知道IP地址，还需要知道mac地址，ARP的作用就是在加入一个新的局域网的时候自动广播一次，告诉局域网内的其他设备，他加入了，其他设备就会存储他的mac和ip，下次通信时就知道包要发给哪个mac地址了。
ARP比较特殊，他是网络层协议，但是工作在数据链路层
有些路由器的控制软件，比如Winbox，就可以直接二层通信，只需要mac即可，完全不需要ip地址，这种就很方便，在IP配置错误的情况下，也能通过mac连接，然后修改正确
二层设备，AP一般都属于二层，他们都是不会主动进行ARP广播的，只会监听局域网内的ARP，并偷偷记录下来，遇到需要转发的包时就知道送给谁了，如果这个包的mac不存在就会直接丢掉
三次设备，路由器，这种设备会在内部维护路由表，联动ARP的mac表，他会自主进行维护，所以他会主动发起ARP广播
还有一个特殊情况，ARP Proxy，这个东西会代理回复或者发起ARP，这个东西也算是搅局者，被干扰的话也比较难辨别
网卡被设置IP时会自动广播一次ARP，同样重启网卡、物理插拔也会重新广播ARP
泛指客户端设备，比如WIFI模块、PC，他们在与PC或者其他东西通信时，内部会维护一个mac和ip的地址表，正常情况下这个表会在加入新网络或者网络断开时重新刷新，或者急速老化
Ping比较特殊，在主动发起Ping时，设备方如果mac表中不存在对应设备，那么就会发起一次ARP广播，询问这个IP的mac是什么
同理，当被ping的设备收到了这个ping包，也会更新自己的mac表，记录下这个来访者
Wireshark本身是被动抓包工具，默认不会主动发送ARP广播；但打开抓包后，可能出现“间接触发”的ARP流量，让你误以为是Wireshark发的;
可能的间接触发原因：
开了Wireshark反而可能导致问题无法复现，主要还是改了网卡的设置，造成网卡重启了，ARP就广播了
设备从SSID：A切换到SSID：B，发包时会重新问一次这个IP对应的mac是谁，如果相同就更新地址表的刷新时间，如果不同那就会替换成新的mac
我们目前出现不上线的问题，基本都是这里，设备端切换SSID后，没有更新他的目标mac地址（PC的mac地址），他发送的地址一直都是错误的，这个mac地址不存在，直接就被丢弃了，所以连上了AP，但是PC收不到。要等到设备主动更新他的mac地址、PC重启、网口重启、网口重设IP、电脑重启等任一条件发生，这个设备才会正常上线。
测试验证设备是否正常上线
这里还混合了一个情况，PC自己有mac表管理，可能在测试的时候会出现pc自己主动发起了ARP，这个会搅和在测试中，某些情况就会受到影响，你分不清是谁让这个情况变好了
查看网口设备
netsh interface ipv4 show interface
Idx Met MTU 状态 名称
--- ---------- ---------- ------------ ---------------------------
1 75 4294967295 connected Loopback Pseudo-Interface 1
7 25 1500 disconnected WLAN
19 25 1500 disconnected 本地连接* 9
10 25 1500 disconnected 本地连接* 10
11 25 1500 connected 以太网
23 5 1500 disconnected 以太网 2
14 35 1500 disconnected 以太网 3
22 35 2800 connected ZeroTier One [b6079f73c6ba32c3]
13 65 1500 disconnected 蓝牙网络连接 3
查询具体网络设备的配置
netsh interface ipv4 show interface 7
接口 WLAN 参数
----------------------------------------------
IfLuid : wireless_32768
IfIndex : 7
状态 : disconnected
跃点数 : 25
链接 MTU : 1500 字节
可访问时间 : 35000 毫秒
基本可访问时间 : 30000 毫秒
重传间隔 : 1000 毫秒
DAD 传输 : 3
站点前缀长度 : 64
站点 ID : 1
转发 : disabled
播发 : disabled
邻居发现 : enabled
邻居无法访问检测 : enabled
路由器发现 : dhcp
受管理的地址配置 : enabled
其他有状态的配置 : enabled
弱主机发送 : disabled
弱主机接收 : disabled
使用自动跃点数 : enabled
忽略默认路由 : disabled
播发的路由器生存期 : 1800 秒
播发默认路由 : disabled
当前跃点限制 : 0
强制 ARPND 唤醒模式 : disabled
定向 MAC 唤醒模式 : disabled
ECN 功能 : application
基于 RA 的 DNS 配置(RFC 6106) : disabled
DHCP/静态 IP 共存 : disabled
这里的可访问时间和基本可访问时间就是ARP表中的刷新时间
修改ARP时间
netsh interface ipv4 set interface 9 basereachable=60000
显示地址表
netsh interface ipv4 show neighbors
ARP表项修改
# 设置为 4096 个条目
netsh interface ipv4 set global neighborcachelimit=4096
# 验证修改结果
netsh interface ipv4 show global
neighborcachelimit 是新的取代ARP的，需要独立设置表项大小，PC上ARP的机制或者代号改来改去的，和系统有很大关系
一些大厂的WIFI模块，本身就有类似的测试用例，所以ARP相关机制都会补全，但是一些原生的WIFI模块，二次开发的，这块内容是否有验证，就很值得怀疑了，这个情况复杂，又不容易复现，很容易被各种推脱跳过去了。