从 NAS 上退休的硬盘被用在了监控的存储上了。 随着硬盘使用寿命的接近尾声，感觉就是从高附加值数据到低附加值数据上。监控数据只会保留那么几个月的时间，很多时候都会被覆盖重新写入。 有人问为什么监控数据不保留几年的，那是因为监控数据的附加值实在太低，很少有人返回查看几年前的数据，尤其是对家用的存储来说。 就算是硬盘突然坏掉，相信很多人也不会过多的在意的。 这块昨天从 NAS 上换下来的报警硬盘，运行时间超过 65534 小时，坏的扇区数量也非常多。 有点感觉就是挂在这里看你什么时候坏吧。     从使用小时上来看，这块家用台式机上的硬盘也算对得起使用时间了。   https://www.isharkfly.com/t/topic/15144

很多年的感恩节都是一个暖冬，不会下雨，也不会下雪，更遇不到白色的感恩节。 今年却意外的喜提了白色，新英格兰地区便开始进入了漫长的冬季，突然间有点不习惯了。   https://www.isharkfly.com/t/topic/15143

上了 NAS 后最大的问题在于硬盘是在 24 小时挂电运行。 对于普通的家用硬盘，真的没有办法支撑 NAS 的运行强度。 在短短几年时间，硬盘的坏道已经快速增加到必须要更换的程度了。 如果说非要选什么硬盘，选择针对长期运行而设计使用的硬盘要比普通台式机硬盘更加靠谱。 硬盘有价，数据无价。   https://www.isharkfly.com/t/nas-14-tb/15142  

离开北京的那年美联航和当时的大陆航空公司还没有合并，那个时候都是属于 2 个不同的航司。 在那一年选择离开熟悉的地方远赴重洋，虽然当时搭乘的飞机是大陆航空公司的 CO88，其实并不是从北京飞往旧金山的，是北京飞往纽瓦克的航班。 在后疫情，中美航线终于慢慢有了恢复，看到这一幕确实百感交集。在疫情这三年确实经历了太多太多，有多少人因为航线的中断而没有了选择，又有多少人在人生的最后阶段也没有能够踏上回国的航班。 目前虽然因为各种因素，飞往纽瓦克的航班还暂时没有办法开通，但不管怎么样，看到这些消息总是积极的，作为很多只是平凡的不能再平凡得普通人来说，能获得一张想走就能走的机票，是多么美好的一件事情。 多少年，少年已成为中年，可憧憬美好的未来却从来没有改变过。     发上一张当年北京飞往纽瓦克的的照片，可惜照片没有留下航空公司的标记，被登机口挡住了。 恍如昨日，却已过了一纪。 历史上的一粒尘落在个人身上却是一座山，从来没有想象过回国的路是那么的漫长，熬白了少年头，来去楼已空。 窃以为，只有怀抱着对未来美好的期待，努力并且坚强的面对，最美好的那一刻总在不远的明天，难道不是这样的吗？   https://www.isharkfly.com/t/topic/15132

SharePoint 平台使您能够以在线方式和本地方式轻松地管理和协调业务数据。因为其灵活性和易使用性，公司可以快速采用SharePoint来管理其业务数据。   SharePoint Microsoft 365 一种基于云的服务，由 Microsoft 托管，适用于各种规模的企业。   任何 SharePoint Server 企业都可以订阅Microsoft 365 计划或独立的 SharePoint Online 服务，而不是在本地安装SharePoint Online 部署。 主要来说 SharePoint 可以认为是一个基于云的平台管理软件。 在过去来说，如果每一个部门可能都需要有一个自己的网站来管理相关的文档和表单等等。 这个时候我们就可以使用 SharePoint 来几种管理，针对每个部门可以让他们自己创建一个站点，然后在站点上管理内容。 经过几天的琢磨，学习曲线说不上复杂，但是很多功能需要摸索下才知道。 另外 SharePoint 还提供了一个开发框架，在这个开发框架中可以开发自己需要的 Web Part。 开发使用的语言是 TS，可以在本地开发后上传调试。 Web Part Web Part 这个肯能是对第一次接触 SharePoint 的用户来说比较困惑的地方。 简单点就是 SharePoint 创建页面后，可以在页面上首先进行布局，当布局完成后就需要在你的布局中插入 Web Part 了。 你可以利用 Web Part 提供的功能来实现微软产品内部的调用，同时也可以实现一些复杂的功能。 Web Part 这个组件也是可以自己开发的，如果你有足够的开发实力的话。   https://www.isharkfly.com/t/sharepoint/15127

Web Parts 可以说是微软 SharePoint 的基础组件。 根据微软自己的描述，Web Parts 是 SharePoint 对内容进行构建的基础，可以想想成一块一块的砖块。 我们需要使用这些砖块来完成一个页面的构建。 我们可以利用 Web Parts 在 SharePoint 中添加文本，图片，文件，视频，甚至是动态内容。 添加 Web Parts 在完成页面布局的 Section 后，单击页面布局上面的 Section，上的 X 号，就会弹出一个小窗口。 在这个小窗口可以对我们需要使用的 Web Parts 进行选择后添加。   2023-11-09_22-41-051339×647 29.3 KB   Web Parts 默认上已经有了很多的选择了，但是很多时候可能还是不够用。 没我要的 Web Parts 怎么办 这个时候就需要进行开发了，微软也提供了开发工具，同时也包括了一些开发示例代码，你需要首先把这些代码下载下来后进行编译，然后再上传到你的站点上。 可以访问：GitHub - pnp/sp-dev-fx-webparts: SharePoint Framework web part, Teams tab, personal app, app page samples 连接上的代码，克隆到本地后进行一些修改再上传到你的站点上。     上面的代码修改需要有一定的环境才可以。 NodeJs 的版本需要到 18，同时还需要一些框架基础和编程基础才可以。 这部分的编程都是前端的 JS 编程了，对后端的要求不高。   https://www.isharkfly.com/t/sharepoint-web-parts/15128

我们都知道 SharePoint 是对页面进行编辑的。 对于一些有编程基础的人来说，可能需要对页面中插入代码，这样才能更好的对页面进行配置。 但是在新版本的 SharePoint modern 页面来说，虽然我们可以插入 Embed 组件。 但是 Embed 组件中是不允许提供 Script 和 Html 脚本的。只能插入 iFrame 框架或者 URL 地址。 这个就非常郁闷了。     管理员配置 在 SharePoint 页面中，默认是禁用自定义脚本的。 你需要登录管理员的界面，然后把这个自定义脚本的功能打开才能插入代码。 据说这是基于安全的考虑，但是对我们来说这个就非常麻烦。   很多高级的功能都不能用了，页面的排版也就是能使用 SharePoint 提供的几个样式，一点都不生动。   自定义 Web Parts 对于没有提供的 Web Parts，我们是可以通过自定义组件的方式来添加到我们站点上的。 这里，我们可以用到 react-script-editor 这个组件。 GitHub 的访问地址为：https://github.com/pnp/sp-dev-fx-webparts/tree/main/samples/react-script-editor 我们可以把 react-script-editor 下载下来后进行编译打包后再上传到你的站点上。 这样的话，我们就可以在页面中嵌入相关内容组件了，你可以在这个内容组件上对提供的代码进行编辑。   https://www.isharkfly.com/t/sharepoint/15129

现在的安装包也不省心，有各种版本都不知道怎么选。 根据你安装的环境配置。 amd： 32位X86 amd64： 64位X86 arm： 32位ARM arm64： 64位ARM amd64是X86架构的CPU，64位版。amd64又叫X86_64。主流的桌面PC，笔记本电脑，服务器（包括虚拟机）都在用X86_64的CPU。   arm64是ARM架构的CPU，64位版。苹果新出的电脑在用ARM架构的CPU。   有些路由器和嵌入式设备在用arm64的CPU。 手机和安卓平板电脑最常用的CPU也是ARM架构的。 MIPS是MIPS架构的CPU。有些嵌入式设备和家用路由器在用MIPS架构的CPU。   https://www.isharkfly.com/t/amd-amd64-arm-arm64/15130

如下图，我们在 Docsify 的文档中配置了一个顶部导航。     下面的步骤对顶部导航的配置进行简要介绍。 配置 有 2 个地方需要这个地方进行配置。 首先需要在 index.html 文件中的 loadNavbar: true, 配置上。 然后再在项目中添加一个 _navbar.md 文件。 在这个文件中对导航进行配置。 配置的格式如下图。     当完成上面的配置后，有关顶部的导航就会自动显示了。 Docsify 在配置上还是比较简单的。   https://www.isharkfly.com/t/docsify/15126

对文档的编译，目前的发布方案是越来越注重 MD 的编辑和发布。 针对其他 Wiki 的选择，MD 文件的编辑通常会保留修改记录，同时不依赖中央数据库和其他类型的 Web 应用服务。 随着各大云平台的支持，包括 GitHub Page 和 Google 的 Firebase，通常在免费的情况下就可以获得基于自己域名的文档服务。 对文档内容的修改，也只需要修改 Md 文件就可以了。 Confluence 长期以来，我们都使用 Confluence 来作为我们的 Wiki 系统并且提供内部和外部的使用的。 通常因为 Confluence 有更好的用户授权，但是随着 Confluence 的生命周期的总结，官方要求要不就使用他们的云服务，要不就要自己部署一套云解决方案。 对我们来说这个没有意义，所以我们需要为我们项目中已经公开的文档提供一个归档和方案。 这次，我们决定使用 md 的文档格式，所以我们考虑在 Docsify 和 Hugo 之间进行选型。 Docsify Docsify 主打的就是一个简单。 对个人用户来说，使用 Docsify 是非常好的选择，这个能让个人只专注内容的，而不需要考虑复杂的配置。     例如，上面我们使用的文档工具，对我们来说就暂时足够了，但是在框架的配置上，我们还是觉得过于简单了。 Hugo Hugo 能够做出非常漂亮的文档。 例如 pulumi 的官方文档就是用 Hugo 做出来了。 可以说，这个文档有非常高的水平了，无论从配色还是其他方面来说都非常漂亮。     如果你是公司，并且有足够的技术力量的话，Hugo 通常是你非常好的选择。 部署 上面 2 个平台，都能够使用无服务的方式进行部署。 我们用 pulumi 的文档测试编译后在 Google Firebase 上进行部署。 也能够实现一键部署，能够让用户只专注代码和内容，而不需要专注部署。 总结 如果是个人使用，在技术力量不是非常重复，同时前端能力也不是非常强的情况下，建议使用 Docsify ，因为我们还是需要更多的关注内容。 如果有一定发展规模，并且技术力量足够的情况下，可以使用 Hugo，因为 Hugo 能够提供更多的复杂功能，但是又不会过多增加技术难度。   https://www.isharkfly.com/t/docsify-hugo/15115