机器瓦力

项目是个物流项目，随着业务需求的迭代，地图功能上的使用也是由浅入深。主要由高德地图应用为基础，从一个小白的角度摸索开发及实现业务落地，中间可能走了不少弯路，不过也是成长的过程。

一直进行Vue2.0项目、React16项目的维护开发，Node版本稳定在v14.17.6。最近针对某个社区新项目做二次开发，把Node版本升级到v18.20.2，node-sass兼容性问题无法解决

应用上线一段时间后，在客户交流使用过程中发现，客户会频繁截图分享订单详情页面到微信群中和管理员、付款方核对订单支付状态、金额等信息。而截图只能截一屏，多频率会截取两张图才能完全表达清楚信息。

Flutter APP交付前，因为逐渐接入部分生产数据进行测试，开发与生成环境分离迫在眉睫。从访问限制、启动方式、配置差异等方面优雅分离环境。先后应用两个方案的实践，最终应用了侵入性最小的方案。

制作一个完整的胖容器需要多人参与，每个人都得负责好自身编写的Dockerfile和Shell，经过环境测试后再合并进大的流程中。配置的读取及应用、服务的启动顺序、依赖之间的关系都得把控

旧版概览在设计上过于追求颗粒度，缺乏业务关联性和时效性。随着业务演进，客户日常使用场景覆盖不全，业务模块冗余、零散等问题暴露出来。在“业务导向、技术相辅”的思路下开始整改。

业务上是动态渲染n个主机节点池信息，选择某个磁盘后显示配置下拉框，选中当前选择磁盘的配置。遇到场景问题是单选后右侧配置下拉框2s+才能出现，初步定位是“React需要深度比较对象来找出差异“

Flutter开发的一个体系的APP上线试用了，经过一段时间试用趋于稳定，准备上架各大应用市场。咨询了第三方上架协助，费用高且针对Flutter开发的审核改造开发方自己处理。最终决定自己来搞。

OpenStack和Portal之间的资源同步、资源纳管是确保用户通过Portal所看到和操作的资源状态与OpenStack底层实际管理的资源状态保持一致的关键过程。这种同步不仅有助于提升用户体验..