Anduin Xue
Anduin Xue

Anduin's Tech Blog

All Posts

20
JUL

Restore a deleted branch from Azure DevOps using it's SDK

本文介绍了如何通过Azure DevOps SDK恢复被误删的代码分支的技术方案。文章指出当开发分支被删除后，可以通过Azure DevOps提供的Git API获取分支最后的提交记录，并利用Git引用更新机制重建分支。开发者需要先通过VssConnection建立认证连接，使用GitHttpClient获取分支的推送历史，找到被删除前的提交ID，再通过UpdateRefsAsync方法将分支引用重新指向该提交。这个过程涉及对Git底层引用机制的深入理解，包括如何处理旧对象ID与新对象ID的映射关系。代码示例展示了如何构建GitPushSearchCriteria查询参数，解析返回的RefUpdates数据，并构造GitRefUpdate请求体。特别值得注意的是，文章揭示了在更新引用时将OldObjectId设为全零占位符的技巧，这是实现分支恢复的关键技术点。技术实现过程中涉及的权限控制、项目名称与仓库ID的匹配等问题，为开发者提供了思考空间。当本地执行git fetch后，删除的分支会重新出现在版本历史中。这引发我们思考：如何在团队协作中设计分支保护策略？当多用户同时操作时，这种恢复机制是否具有原子性？如果在不同版本的Azure DevOps中执行该操作，可能会遇到哪些兼容性问题？--Qwen3

C# git Azure Azure DevOps SDK Git Branch Restore
21
JUN

Tips about rules setup for Outlook enterprise users

在信息洪流中如何构建高效的邮件过滤体系？当每天面对成百上千封邮件时如何让重要信息浮出水面？企业用户在Outlook中设置规则的艺术在于建立分层处理策略——从垃圾信息的精准拦截到核心项目的主动捕捉从个人事务的智能识别到团队协作的分类管理。通过构建优先级明确的规则链：首先将GitHub通知Teams消息等固定来源的噪音批量归类继而用关键词触发关键项目警报再通过收件人识别锁定个人沟通最后按团队邮箱分流讨论内容最终形成"重要-次要-其他"的三维信息矩阵。这种规则架构不仅需要识别邮件的本质属性更考验对工作场景的深层理解：当你的规则体系开始自动运行时是否真正实现了信息的精准触达？在自动化分类背后隐藏的其实是对工作优先级的哲学思考——究竟哪些信息值得你立即响应哪些可以延迟处理哪些应该永久归档？邮件规则设置不仅是技术操作更是工作认知的具象化过程你的Outlook规则是否反映了你对工作的独特理解？--Qwen3

Outlook Rules Setup Email Organization Tips Mail Automation Efficient Workflow Inbox Management Guide Important Emails Alert
31
MAY

软件工程领域中的逆全球化趋势

过去的二十年间软件工程领域的全球化趋势曾被视作技术发展的必然方向跨国企业通过统一的云基础设施和分布式系统实现全球服务覆盖CAP定理指导下的分区容忍性设计让跨地域数据同步成为可能微软的CosmosDb和国内的TiDB等技术验证了这种模式的可行性但2020年后的地缘政治变化正在改写这一逻辑国家间的数据流动面临前所未有的信任危机客户开始要求服务必须在物理隔离的空气墙环境中依然完整运行这种需求催生了软件工程的逆全球化转型当分布式系统的分区不再由网络延迟定义而是由政治和技术壁垒切割时传统的SaaS模式面临根本性挑战私有云的本地化部署和数据主权的重新定义成为刚需更极端的场景要求将整个组织结构作为服务交付对象而非仅仅是代码这种变革不仅颠覆了技术架构更重构了商业逻辑当数据跨境流动需要如同人员出入境般办理数字签证时当软件销售从交付产品转向交付人才与组织时我们是否正在见证一种新的数字时代地缘政治如何在CAP定理的框架下重新定义软件工程的边界？当全球化与逆全球化的力量在代码层面持续角力时未来的技术架构将如何在信任与安全的天平上找到新的平衡点？--Qwen3

Multi-tenant China Software Development AirGap Globalization CAP Theorem
27
MAY

Build a package that can be used in browser and node with TypeScript

本文探讨了如何构建一个兼容浏览器与Node环境的TypeScript库项目并实现标准化发布。通过初始化npm项目配置TypeScript与Webpack构建工具链创建UMD模块化输出方案开发者可以将核心逻辑封装为类型安全的类并通过Webpack配置实现生产环境代码压缩与多环境适配。文章展示了从项目结构搭建到tsconfig编译选项设置再到webpack打包配置的完整流程最终通过npm发布实现代码共享。这种构建方式既保留了TypeScript的类型优势又通过UMD格式兼容了不同运行环境的调用需求。当开发者需要在前端框架中复用算法或构建可复用组件时如何平衡类型系统与兼容性如何设计模块的导出结构以及如何优化打包体积成为值得关注的技术命题。--Qwen3

Web npm TypeScript node webpack JavaScript Front-end
21
MAY

Use Azure Key Vault to store connection strings for App Service.

本文探讨了如何通过Azure Key Vault解决Azure App Service协作管理中的敏感信息泄露风险。传统环境变量配置方式存在隐患，当多人协作时可能导致数据库连接字符串暴露进而引发意外操作。文章提出使用Azure Key Vault作为安全中间层，通过权限分级管理实现服务托管与密钥保护的分离。具体方案包括创建独立密钥库、启用基于角色的访问控制、配置托管身份验证以及构建密钥引用链路。这种架构不仅保障了连接字符串的机密性，更允许团队成员在无需知晓具体凭证的前提下完成应用服务的日常维护。文章最后引发思考：当安全需求与协作效率产生冲突时，如何设计既能满足权限最小化原则又不阻碍团队协作的技术方案？你是否考虑过如何在不暴露密钥的前提下实现团队协作？或者，是否有更高效的安全策略等待探索？--Qwen3

Azure App Service Azure Security Key vault Environment Variables Azure Key Vault
20
MAY

Programmatically connect to the remote server via SSH and execute remote command.

文章围绕如何通过程序化方式实现SSH远程服务器连接与命令执行展开重点探讨了.NET Core环境下借助SSH.NET库完成自动化运维任务的实践路径。开发者通过创建控制台项目并集成SSH.NET库实现了从连接认证到命令执行的完整流程验证了使用代码替代人工SSH操作的可行性。示例代码展示了如何通过Renci.SshNet命名空间下的SshClient类构建连接执行"apt upgrade"命令并输出执行结果同时处理连接状态与错误信息。这种程序化方案为服务器管理工具开发提供了新思路但也引发关于自动化运维边界与风险的思考——当机器接管了原本需要人工判断的运维操作后如何确保指令执行的准确性如何处理敏感操作的认证安全如何应对网络波动导致的连接中断等问题。文章提供的代码框架虽然实现了基础功能但实际应用中可能需要更复杂的逻辑处理例如异步执行、结果解析、异常重试等机制的补充。SSH.NET作为支持并行操作的开源库其文档中提及的高级特性如端口转发、文件传输等功能是否能与现有代码形成更强大的组合如何构建可扩展的服务器管理架构这些都值得进一步探索。当代码开始远程操控物理服务器时我们是否正在见证运维工作的范式转移？自动化程度的提升是否会让服务器管理变得更加透明还是反而带来新的复杂性？这些问题或许能在文章提供的实践基础上找到启发性的答案。--Qwen3

C# .NET Core bash Linux SSH Renci.SshNet
01
APR

Use JetBrains code quality analyzer to prevent checking-in bad C# code

本文介绍了如何通过JetBrains ReSharper代码质量分析工具在Azure DevOps和GitHub Actions中自动拦截不符合规范的C#代码提交。文章展示了在持续集成流水线中集成ReSharper的YAML配置方案，包括安装代码质量分析插件、定义检查任务优先级以及通过.editorconfig文件自定义规则集的完整实践路径。特别指出在Azure DevOps中将代码检查任务置于构建之后测试之前可避免无效代码测试浪费资源，并揭示了无需购买ReSharper授权即可通过dotnet工具链实现本地代码质量检测的免费方案。文章引发思考：当自动化代码检查与团队开发习惯产生冲突时，如何平衡代码质量标准与实际开发灵活性？如何通过规则调整既避免过度约束又确保核心代码规范？读者或许会好奇：在云原生开发盛行的当下，如何将静态代码分析与动态测试策略结合形成更全面的质量保障体系？--Qwen3

C# Azure DevOps JetBrains Resharper Code Quality Pipelines
28
DEC

FFmpeg 用法概览

FFmpeg是一个强大的多媒体处理工具支持视频音频的转换剪辑合成等操作核心功能包括推流实时编码调整分辨率速度剪辑视频整合字幕音频及反转视频等推流时可选择复制流模式或实时编码模式实时编码需指定分辨率编码器比特率等参数整合视频和音频可通过映射流并指定编码器实现字幕处理支持VTTASS格式并可将其烧录到视频中调整分辨率使用-s参数调整速度通过setpts滤镜控制音频操作如调整音量使用volume滤镜剪辑视频用-ss和-t参数反转视频时需注意大文件处理策略推荐分块处理后合并推荐的项目如SRS可实现RTMP流的接收与转码flv.js则支持浏览器播放FLV流整体功能覆盖视频处理全链路适合多种应用场景--Qwen3

bash Live Streaming FFmpeg Video Editing SRS flv.js
22
DEC

C# run tasks in a threads pool with fixed size

本文提出了一种基于C#的固定线程池任务调度方案通过线程安全队列实现动态任务分配解决了多核CPU资源利用与任务池扩展性之间的平衡问题。方案通过SafeQueue实现并发安全的任务队列管理CannonQueue服务则采用动态调度策略在保持最大并行度的同时支持任务池的动态扩展。当检测到线程空闲时自动触发任务分配机制确保核心资源的持续利用。针对依赖注入场景设计了QueueWithDependency方法通过服务作用域隔离解决了实体框架等依赖的生命周期问题。方案支持三种使用模式：即时启动的队列模式延迟启动的批量处理模式以及无等待的火并忘记模式。实现中通过Task.WhenAny实现非阻塞任务监控并通过日志记录实时展示任务运行状态。该方案引发的思考包括：如何在不同硬件配置下自适应调整并行度？当任务处理时间差异较大时如何优化资源分配？如何设计任务失败的重试机制？以及在高并发场景下如何平衡内存占用与吞吐量？--Qwen3

C# Async Task Multi-Threading async programming task queue
09
DEC

Display code coverage information for .NET Core project using Azure DevOps.

本文深入解析了如何在Azure DevOps中为.NET Core项目展示代码覆盖率数据，通过构建管道配置和测试结果分析，揭示了软件质量保障的关键路径。文章不仅提供了从构建管道创建到覆盖率徽章生成的完整操作链，更引发了对测试覆盖度与代码质量关系的深层思考——当测试覆盖率显示为87%时我们是否应该满足？如何通过覆盖率数据识别潜在的测试盲区？在跨平台开发场景中Linux系统仍不支持代码覆盖率收集这一现状是否会影响开发策略？文章通过Windows平台专有的构建配置要求，提示开发者在选择CI/CD环境时需权衡工具链兼容性与测试完整性。当覆盖率徽章以动态形式展示在readme文件中时这种可视化手段如何影响团队对代码质量的感知？更重要的是当测试通过率与覆盖率指标出现偏差时我们该如何解读这两组数据背后的技术含义？最终文章抛出一个值得所有开发者思考的问题：在追求100%覆盖率的过程中我们是否忽略了测试用例设计本身的质量？这种对测试方法论的反思或许比单纯追求数字更为重要。--Qwen3

.NET Core Azure DevOps .NET Test MSTest Integration Test Code coverage GitHub
06
DEC

ASP.NET Core Integration Test using MSTest

本文探讨了在ASP.NET Core集成测试中替代官方推荐xunit框架的可能性问题。通过实践验证表明MSTest可以完美替代xunit实现完整测试流程文章展示了如何通过移除xunit依赖并安装MSTest组件构建基于MSTest的测试架构重点解析了测试服务器的启动机制与HTTP请求的自动化验证方案。测试类通过动态创建服务器实例并绑定指定端口实现了与真实环境的模拟交互同时通过[TestMethod]和[DataRow]特性构建了可扩展的测试用例体系。值得注意的是测试框架的切换并非简单的工具替换而是需要重构测试生命周期管理尤其在服务器启动与资源释放环节必须建立严格的[TestInitialize]和[TestCleanup]机制以确保测试环境的隔离性。这种测试架构的迁移启示我们软件测试的灵活性不仅体现在框架选择上更在于对测试流程的深度控制。当面对不同测试框架的适配问题时我们是否应该优先考虑开发习惯还是框架特性？在测试稳定性与框架扩展性之间是否存在最优解？这些问题或许能引发开发者对测试策略更深层的思考。--Qwen3

ASP.NET Core C# .NET Core Test MSTest Functional Test Integration Test
14
OCT

Fire and forget in ASP.NET Core with dependency alive

在ASP.NET Core中实现fire and forget模式时，开发者常通过Task.Run启动异步任务但可能忽略依赖项生命周期管理。当控制器触发耗时任务后自身即被释放，导致注入的依赖可能提前销毁从而中断任务执行。文章揭示了直接在控制器中调用Task.Run的潜在风险，提出通过单例服务CannonService解决依赖存活问题的创新方案。该服务利用IServiceScopeFactory动态创建作用域，确保任务执行期间依赖项始终有效。通过将耗时操作迁移至单例服务中执行，既避免阻塞主线程又能保持依赖存活，同时引入异常处理机制增强任务健壮性。这种设计模式突破了传统依赖注入的生命周期限制，为长时异步任务提供了优雅的解决方案。文章最后抛出值得深思的问题：当任务依赖多个作用域服务时，如何平衡资源占用与任务可靠性？当系统负载剧增时，这种基于Task.Run的调度策略是否存在潜在瓶颈？或许我们该重新审视fire and forget在现代云原生架构中的最佳实践。--Qwen3

ASP.NET Core C# Async Fire and forget dependency injection singleton service