Software Development

01

SEP

我为什么构建了 Anduin OS

Anduin OS 1.0 is a Linux distribution that aims to provide a user-friendly and stable operating system. The author initially attempted to modify Ubuntu server to create their own distribution, but encountered difficulties with the installation process. They then decided to build their system from scratch using Debian tools and combining them with popular and stable Ubuntu software sources. The author discusses the challenges they faced in creating an installer and the need to differentiate between the installer and the main system. They also explore the design philosophy behind Anduin OS, which draws inspiration from Windows 11 UI elements. The author reflects on the importance of a reliable application store and the challenges of implementing a package management system. Ultimately, they decide to let users choose their preferred package management method. The blog post also touches on the topic of secure boot. Overall, Anduin OS 1.0 offers a unique approach to creating a Linux distri...--GPT 4

16

JUL

应用商店、包管理……每天都会使用的东西有什么开发难度？

现代软件开发中，应用商店和包管理是我们每天都会使用的东西。然而，这背后隐藏着许多开发难题。安装一个包可能涉及到多个依赖关系，而这些依赖关系构成了一个有向无环图。基本需求包括避免重复安装相同的依赖、包与包之间的隔离、升级和降级的允许性、查询包的来源和版本等。全局包管理器如APT、yum和pacman可以解决这些问题，但是无法解决依赖冲突和破坏性的升级降级问题。分治思想将大问题拆分成小问题，例如将应用拆分成微服务，但是会带来包的重复安装和磁盘空间占用的问题。Nix是一个函数式的包管理器，通过不可变性和平坦的包存储解决了依赖冲突和包的隔离问题。Nuget则采用动态链接的方式解决依赖冲突。其他包管理工具如winget、snap和flatpak也有各自的解决方案。然而，包管理实际上没有万能解决方案，目前主流的做法是结合Monolithic的包管理、Docker和虚拟机来解决依赖冲突问题。虽然应用商店给我们带来了便利，但是背后的复杂性是巨大的。当我们开始自己分发软件时，才会意识到这个世界并不是那么简单。--GPT 4

Store nuget apt package manager Application Nix

15

JUL

在 2024 年学习汇编还有必要吗

摘要：本文讨论了操作系统和应用程序的诞生顺序，并介绍了依赖倒置原则和构建可插件应用程序的重要性。文章指出，操作系统和应用程序的诞生并不分先后，而是依赖于应用二进制接口（ABI）。ABI定义了应用程序如何与操作系统交互，是二者的桥梁。文章还探讨了操作系统的核心功能和抽象层的作用，以及汇编语言和操作系统课程对计算机科学理解的重要性。最后，文章回应了一个杠精的观点，指出应用程序并不一定必须依赖操作系统。--GPT 4

06

FEB

基于 Docker Swarm Mode 建设你家里的数据中心！

在这篇博客中，我们将深入探讨如何使用 Docker Swarm Mode 建设家庭数据中心。文章首先介绍了 Docker Swarm Mode 的基本概念，包括其特性、优势以及与其他技术如 Kubernetes 的对比。接下来，我们详细阐述了如何在家庭环境中配置和使用 Docker Swarm Mode，包括网络设置、数据存储、服务管理等关键步骤。在文章中，我们还讨论了使用 Docker Swarm Mode 建设数据中心的一些潜在问题和挑战，例如网络安全、数据备份、系统稳定性等。同时，我们也提供了一些实用的解决方案和建议，帮助读者在实际操作中避开这些问题。文章最后，我们展望了 Docker Swarm Mode 在家庭数据中心建设中的未来发展，包括可能的新特性、技术趋势以及对现有架构的影响。我们相信，随着 Docker Swarm Mode 的不断发展和完善，它将成为家庭数据中心建设的理想选择。这篇文章能否启发你思考如何利用现有的技术和资源，打造你自己的家庭数据中心？Docker Swarm Mode 又有哪些潜力和可能性等待你去探索和发掘？希望你在阅读本文后，能找到你自己的答案。--GPT 4

bash Linux Server Docker Container Docker Swarm Cluster Swarmpit

31

MAR

在2023年学习传统软件开发技巧还有意义吗？

在2023年，AI技术的飞速发展让人们纷纷质疑传统软件开发技巧的价值。本文探讨了AI在软件工程中的应用，以及学习传统软件开发技巧的意义。尽管AI可以提高开发效率，甚至取代某些工具，但学习传统软件工程仍然具有重要意义。正如汇编语言为我们理解计算机底层原理提供了基石，传统软件工程也是未来基于AI的软件工程的基础。对于计算机专业的学生，适应AI辅助软件工程的同时，也应该学习传统技术。未来工程师的要求将更高，需要全面了解硬件、电路、操作系统、面向过程、类、依赖注入、组件、包、接口以及AI等方面的知识。因此，建议将70%的精力放在AI相关领域，20%的精力放在传统软件工程，10%的精力放在考古技术上。这样的学习分配将有助于应对未来软件工程领域的挑战，提升个人竞争力。那么，在AI时代，你准备如何分配你的学习重心呢？--GPT 4

03

JAN

UWP 一个技术上成功但商业上失败的框架之死；一个现代的操作系统究竟应该提供什么？

本文探讨了UWP（通用Windows平台）框架的技术优势与商业失败。UWP框架解决了许多Windows操作系统面临的问题，如应用商店、版本管理、依赖管理、存储空间管理、自动更新等。然而，尽管技术上表现出色，UWP在商业上却未能取得成功，原因包括：市场份额丧失、应用质量不高、开发难度较大等。在现实中，UWP已经失去了市场竞争力，许多开发者和用户放弃了这个框架。微软自家的UWP应用质量也不高，功能稀缺，导致用户对UWP的印象普遍不佳。此外，开发一个UWP应用的难度并不低，许多开发者更愿意选择其他框架。总之，尽管UWP在技术上具有诸多优势，但由于商业上的失败，它已经失去了生存的希望。新的开发框架MAUI正在崛起，但它放弃了UWP的优点，回归了Win32的开发模式。这让人不禁思考，未来的应用是否还会面临类似UWP的命运。--GPT 4

C# Microsoft Windows Microsoft Store UWP

29

MAY

Why do low-code development is a pseudo requirement?

本篇博客探讨了低代码开发是否真的是一个伪需求。首先，作者指出网络页面和应用程序并非所见即所得，使用低代码开发工具在短期内可能容易上手，但在稍复杂的场景中，以及在重用和扩展方面，最终可能会面临很多障碍。其次，作者提到低代码开发平台本身存在较高的学习成本。尽管低代码开发可以降低学习成本，但作者认为这可能存在一些误解。例如，公司购买低代码开发框架，是否真的能让产品经理和设计师直接进行应用开发？此外，作者认为代码本身是对现实世界的抽象，而低代码开发在短期内无法更为通用。开发本质上是人类试图对现实世界的过程进行抽象。我们已经熟悉的形式化语言抽象具有很好的理论基础，而低代码开发放弃了这些高质量的抽象方法，期望计算机和AI能正确理解它（并不一定成功）。作者还提到了WinForm和WPF等框架，并指出它们本质上并非低代码开发框架，而只是桌面应用开发框架。最重要的是，没有开发者认为Visual Studio设计器看到的内容一定与程序运行时看到的内容相同。最后，作者认为低代码开发框架确实存在市场，但并非媒体宣传的那么夸张。当需求不复杂、开发者具备基本的开发素养、相关基础设施（如API）已经建立，且不想投入过多时间、精力和金钱时，低代码开发框架是一个不错的选择。然而，媒体宣传的“产品经理自己搞定开发工作”的说法则显得十分可笑。那么，低代码开发真的是一个伪需求吗？或许这取决于具体的应用场景和开发者的需求。--GPT 4

Software Development Low Code PowerApps WYSIWYG

24

SEP

找到玄学问题的根源的方法 - 夹逼调试法

本文介绍了一种解决玄学问题的方法——夹逼调试法。玄学问题指的是那些在正常情况下能够正常工作，但在某些特定环境下无法正常工作的问题。夹逼调试法的核心思想是通过两个方向共同限制作用，使得问题根源的可能范围集中在最小化的条件变化中。具体操作方法包括构建一个理想环境，然后逐一对比出现问题的环境和理想环境之间的差异，通过调整这些差异，观察问题是否得到解决，从而找到可能导致问题的原因。需要注意的是，夹逼调试法只能找到可能的原因，而不是必要、充分或充分且必要的条件。因此，该方法适用于需要快速定位可能原因的情况。本文还通过两个实际问题，详细演示了如何运用夹逼调试法进行问题定位和解决。在解决问题的过程中，我们可以发现夹逼调试法具有一定的实用性和效率，对于解决那些难以预料的因素导致的问题具有一定的参考价值。那么，在面对类似的玄学问题时，你是否会尝试运用夹逼调试法来寻找问题的根源呢？--GPT 4

21

JUN

Tips about rules setup for Outlook enterprise users

In this blog post, we discuss how to set up rules in Outlook for enterprise users, helping them manage and organize the thousands of emails they receive daily. With the proper rules in place, users can ensure they never miss important emails while also focusing on group mailboxes and automatically sorting emails into different folders based on their usage. To begin, it's essential to learn how to use the Outlook app to manage rules. A helpful resource for this can be found at [How to set a rule where my name is not in To or Cc field in Outlook? (extendoffice.com)](https://www.extendoffice.com/documents/outlook/4636-outlook-rule-where-my-name-is-not-in-to-cc.html). The blog post then shares a personal configuration for creating rules, which should be set up in a specific order: 1. Clean some useless content by moving emails from specific senders to designated folders, stopping further rule processing after moving. 2. Alert focused content by moving emails containing specific project ...--GPT 4

31

MAY

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

在过去的二十年，全球化在软件工程领域取得了长足的发展，然而近年来，逆全球化的趋势逐渐浮现。在这篇博客中，我们将探讨这种趋势背后的原因以及它如何影响我们构建和维护软件的方式。在全球化的背景下，我们曾经认为构建的应用应该越来越“全球化”，即应用能够全球布局，全球服务。然而，随着近年来国际间政治局势的变化，人与人之间的不信任逐渐加剧，客户对网络和互联网耦合的服务产生了不信任。这种不信任导致了软件工程领域的逆全球化趋势。在逆全球化的趋势下，我们不能无条件地将整个地球视为一个可以进行数据最终一致性的分区。考虑到许多国家的军队、机关、科研等都逐步面向私有网络和空气墙的模式，我们在尝试面向这些客户时，也必须考虑在完全本地的部署情况下应用的维护与运行。这意味着我们需要重新思考软件的构建和维护方式，以适应这种新的趋势。容忍空气墙（AirGap）是这种新趋势下的一个关键问题。在面对这种情况时，我们可能需要考虑将私有云打包提供给客户，甚至将一整个系统，连带一整套有完整维护、更新、管理经验的组织结构一起交给他。这可能会产生截然不同，甚至是如今无法想象的合作模式：未来销售软件，销售的不再是光盘，不再是程序，而是销售的人，销售的组织结构。虽然站在2021年的视角来看，这种逆全球化的操作还非常疯狂，但现实往往正是这样。在这样的背景下，我们需要重新审视我们构建和维护软件的方式，以适应这种不断变化的世界。那么，我们将如何应对这种逆全球化趋势，以确保软件工程能够继续发展和繁荣呢？这是一个值得我们深入思考和探讨的问题。--GPT 4

Multi-tenant China Software Development AirGap

01

APR

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

在本博客中，我们将探讨如何使用Azure DevOps和JetBrains代码质量分析器自动检查C#代码质量并拒绝包含不良代码的Pull Requests。首先，我们需要安装JetBrains代码质量检查器，然后将其添加到构建管道中。在构建任务后和测试任务前插入此任务，以确保在没有构建项目的情况下不会引发问题。并选择合适的严重性级别，以便在检测到无效代码时使管道失败。对于GitHub Actions，我们也可以轻松地将其应用到GitHub Actions中，只需参考给出的yaml代码即可。此外，我们还需要在本地检查代码质量并生成报告。虽然购买ReSharper是最好的方法，但我们还是可以免费使用代码质量检查工具。通过运行给出的命令，可以在本地安装语法检查工具并运行检查。为了调整检查级别或抑制警告，我们可以创建一个.editorconfig文件并添加相应的规则。通过参考给出的链接，我们可以查询.editorconfig的所有级别属性。如此一来，我们就拥有了一个完整的C#代码质量自动检查解决方案，而且是免费的！祝您编码愉快！在这个过程中，你有没有想过如何根据项目需求调整代码质量检查标准？或者如何在本地生成详细的代码质量报告以进行调试和优化？--GPT 4

C# Azure DevOps JetBrains Resharper Code Quality Pipelines

10

MAY

软件定制行业为何应当发展软件订阅制？

在当前软件定制行业中，普遍存在的问题是软件质量低劣、漏洞百出，对企业的扩展和用户体验造成严重影响。这主要是由于现行的商业采购模式导致的，而发展软件订阅制可能是解决这一问题的有效途径。订阅制意味着甲方按时间和用量付费，购买软件的使用权和保证软件可用性的服务，而非购买整个软件源码的知识产权。这将有助于改善乙方的开发流程，提高软件质量，降低甲方的风险，并且对双方都有更大的利益。订阅制的软件定价可以更加灵活，降低甲方的初期试错成本，有助于乙方扩展市场。此外，乙方需要靠精准的定价来保证稳赚不赔，实现企业的健康发展。以微软的Office 365为例，采用订阅制销售，使得普通用户更容易接受，同时提供优异的技术支持和高软件可用性。尽管订阅制在宏观和微观层面上具有诸多优势，但也存在一些问题，如数据安全、财务资产申报等方面的挑战。然而，随着越来越多的软件开发企业开始向服务转型并取得成功，订阅制将成为软件定制行业的主流和未来趋势。我们有理由相信，这将显著提高各行各业的IT服务质量。那么，订阅制是否真的能够改变软件定制行业的现状？企业如何应对订阅制带来的挑战？这些问题值得我们深入思考。--GPT 4

DevOps China Software Development SaaS Subscription

Anduin's Tech Blog