我的电脑是我为数不多的安全感的来源,电脑配置的一大部分又是软件;为了延续我的安全感,也为了以后换新配置方便,把我目前能想到的——并不调查,以证实其亲密常用——陈列于此。
Git
。否则?.Net X
。就是希望WinUI3
和MAUI
早点出。急死了!Node
。没个Node
还能搞事情?PowerShell
。我觉得好;虽然有人说CmdLet
破坏了命令行的简洁性,但我觉得反正有Alias
;工程化的可拓展机制才是基石。自己都不知道自己装了多少
CLI
工具。凭印象——上面也说了。
C# 9.0
已经有可以替代的选项了。没有人能够不漏任何细节地把一件事物完全记住,所以我们需要笔记;结构化是编程带给我们的一大启发,所以我们需要思维导图这种自然的结构化模型。通用技术的学考部分很杂啊……而且容易对,容易错,分值大。故特地整理了笔记在这。
个人博客是展示自己的一个平台。自己搭建博客有着很强的可定制性,同时也很能彰显开发者的身份特征。
我对前端知之甚少,所以一开始就只是Fork了一个仓库,在里面加了几篇文章而已。后来想搞一个评论功能,但是却发现很困难。一个懂前端的同学建议我不要用Jekyll
——原来我一直在用Jekyll
啊——而去用Hexo
。
我于是“蹒跚学步”,终于成功迁移到了Hexo
上。
为了配合Hexo
和GitHub Pages
,我按照官方文档,安装了个hexo-deploy-git
,本地编辑一下,要部署的时候就直接hexo clean && hexo deploy
——方便快捷,用得我“不亦乐乎”。
但是我随后发现,每次push
到GitHub
上面的并不是整个文件夹,而只是编辑好的public
文件夹。这不很安全,会面临数据丢失的风险。
我因此决定自定义部署,更好符合我的需求。
本地在不对原来文件进行任何更改的情况下,另建一个仓库,桥接原有文件和GitHub
仓库。把一个仓库分成两个分支,main
分支用来放编译好后的文件/public/*
,source
分支放必要的——也就是去掉.gitignore
中的目录后的——源文件。
每一次更新主要分为四步:
Hexo
进行编译。GitHub
仓库。GitHub Pages
进行部署。我写了PowerShell脚本,欢迎大家下载~
]]>UML是好是坏、有用无用,从来没有过统一的意见;我想未来也不会有。有人把UML捧上神坛,也有的人高举“UML无用论”的大旗。当然,从辩证的角度来看,UML绝对不是“有用”或“没有用”就可以概括的;它有贡献,也有缺陷。
于我而言,我则想套用一句著名的话来概括:
UML已死,UML万岁。
建模,就是建立模型,就是为了理解事物而对事物做出的一种抽象,是对事物的一种无歧义的书面描述。
文学创作是写字吗?显然不是;文字只是文学创作的突出特征和最主要载体。
开发软件是写代码吗?这显然也是片面的。代码是软件的原材料,但是代码并不能指定自身的组织方式、实现功能种种。
我们需要思考软件,而不只是写软件。
UML就给人们提供了思考软件的范式,也就是建模思路。这是UML的核心和真正价值所在。
UML给人们提供了连接宏微观的、多样而全面的、广泛认同的、图形完整的思考软件本身的角度,奠定了大型软件开发设计的思想基础。
人的思维具有天生的宏观性,一个看似小巧的功能往往是许多代码的集合。但是人的思维也具有陷入微观的惯性,一个设计决策的会议很容易变成技术细节的争论,尽管设计的确需要技术层面的支持。
而UML很好的统一了宏观和微观两者。
一方面,UML使得人们能够较为流畅和完整地表达想法,而不会受限于语言、平台等技术细节。
另一方面,在人们利用UML表达的同时,其实也就开始思考软件的实现,为软件的开发制定了一个并不完善、但是非常重要的蓝图。
软件除了代码之外,还包括它的实现功能、组织方式种种。我们不可能找到一颗“银弹”,用一种统一的方式来描述这个软件。这是由软件本身传达的信息类型的多样性决定的;更根本地说,是由于人的意识本身的复杂性决定的。
UML对于人们找到的一些描述软件的模型进行了修改与筛选,使得这些模型在现有范围内能够以较少类型传递尽可能多的信息,同时避免大量的交集冗余。
UML的建模思想和角度不是独创的,而是总结出来的,是人们在长期历史实践当中产生的,是符合人们的思维的,因此有着良好的基础,很容易理解,也很容易应用。
软件的本质是信息。软件建模的关键就是保障信息传递的损耗达到最小。
举一个例子说,我经常会遇到不同东西之间的交互。在了解“序列图”之前,我往往会画几个方块来表示这些事物,用一些相连的线来表达通信。但是如果我想要表示一个有多个事物多次协作完成的完整过程,我往往无法表达,甚至于遗漏信息。序列图则列举了这些信息,可以达到“最低损耗”的要求。
类图随着类图思想的深入人心早已普及。
上面举到的“序列图”的例子确实帮助我用更完整的头脑思考交互。
状态图、配置文件图等等也是对软件各个方面非常优秀的建模方案,可以很好地满足软件建模的需求。
UML的很多思想早已经渗透,只是被它的有些可笑的学究表面遮盖了而已。
UML作为一个促进思考的工具是具有突破性意义的。但是作为一门“图形建模语言”,它是失败的——或者更根本地说,本身就是不合适的。除此之外,它也遗留了一些其它问题,同时还面临着形式被时代抛弃的窘境。
本来用图形语言进行建模是一种非常自然的行为,但是过于死板、复杂、细碎的图形标准会让建模过程变得脱离自然、甚至枯燥。
作为一项建模语言,商业化既满足了一段时间内个人或企业对于使用UML的需求,同时却也将UML推向了产业化使用的坟墓。
究其原因,是因为:UML商业化——即UML工业制作软件的需求本质上源于UML图形系统的膨胀。这让UML并没有集中力量解决这一自身问题,导致它没能做到与时俱进。
当代软件用户群体的变化导致了软件类型、特征在比例上的变化,导致了开发过程的改变,削弱了UML作为一门语言的用处。
世界观决定方法论。
“哲学家的工作是认识世界,但更重要的是改造世界!”
说英语的人比说中文的人对于时态有更加清晰的概念。就算会很多单词,如果没有掌握时态,不过也是Chinglish,不是真正的English speaker。
UML给人们最大的宝藏,就是建模语言本身。作为一门语言,它显得过于臃肿、并不那么实用;但是其中的建模概念为人们打开了一扇窗户,让人们得以用“专业术语”观察和思考软件。换句话说,这个语言不是让人们说的,而是让人们用这种方式思考。说出来反而影响了思考。
另外,UML作为展示软件架构的载体也是一个非常好用的工具。
UML应当吸收系统论、控制论等等学科。因为软件开发本身就是一门交叉学科。
UML已死,UML万岁!
]]>很早之前就有人提出了无纸化办公的概念。随着信息技术、互联网技术的发展、以及持续的科学大爆炸给人类带来的自豪感、满足感,人们逐渐觉得:无纸化办公是理应现实的。当然——这些人恐怕是没有亲自尝试过,因为我所碰到的所有人——包括我自己——都告诉我——没有纸而只有电脑和网络的世界事实上是很不方便的。
这对于理想主义者来说当然是十分离奇的:电脑、互联网以及其它各种新技术的诞生,难道不就是为了、也不正在便利着人们的生活吗?为什么还会出现这样的情况呢?
这时一定就会有人说了:因为大部分人不会用电脑,或是没有好的设备——但这并不代表无纸化办公不现实!
他(她)看来是觉得现实不现实是理论上的了;可恰恰相反:
现不现实往往不是想象的、理论上的、“应该的”;现实中不可控的、真实存在的因素才是“现实性”的体现。
当一些“误差”大到可以显性地影响人们生活了,这些误差还应该被忽略吗?
我不觉得有多少人用正版Office 365。如果能用微软或者谷歌全家桶,无纸化办公的体验是不会差的。但是这只是如果。现实和想法是割裂的;全家桶的良好体验和价格、学习曲线等相比,诱惑力黯淡。
谁都知道Office 365很贵。微软的广告天花乱坠、美轮美奂。但那只是有钱人的现实——普通人的梦。
Office全家桶软件有多少个?Word,Excel,PowerPoint ,Yammer,Project,Flow,Sway,OneNote,Visio,Team,Access,Outlook,Publisher……如果你能熟练掌握、协同操作这一系列软件,那么用起来一定是如鱼得水。可是这里面没有多少软件是常用的——有的(比如Flow)可能只是为了处理一次——但却要付出更多的努力;常用的软件也不会开发出所有功能——大概只是码码字,做几张幻灯片,列一张清单而已。过度丰富的功能开始拔高学习曲线了。
无纸化办公想要用得好,前期的环境搭建很重要。但是需求都是中途跳出来的,不会允许你把所有的都提前安排好。由于软件产品本身固有的复杂性,软件在提高本身生产力的同时也不可避免会增加琐碎事情的数量、复杂程度。
微软的广告向来是很富有科技感的——但是又有多少人有触屏电脑、电子笔呢?
这是最直接的。你不可能用Office Online服务(包括OneDrive)。你也用不了Google系列软件。没话说;你只能用一个广告多多、功能缺失的WPS。
有多少人是用U盘储存文件的?又有多少人是用U盘储存需要拷贝的文件的?这就已经很混乱了。试想:你在电脑里有v1的文件,拷贝了v1的去修改成为了v2,然后突然发现用云更方便,于是就把v2放到了云上,回家修改;第二天又去修改,结果没有网了,只好拿出v1,心里想着“反正v2也没有改什么东西”,修改出了v3……
又是一天,你觉得自己应该吧所有的东西都放在云上,就不会混乱的,这时候你发现它竟然要订阅!于是你就挑选了一些放在上面,存储割裂的恐怖境地就这样延续了下去……
哪些东西在本地,哪些在云端?是真子集关系,还是相等关系,还是空交关系,或是有所重叠?没有一个完整的记录(也很难有一个完整的记录),因此云端存储对于那些在本地已经有了大量文档、需求十分灵活的人来说门槛极高。当然如果你一直都在里面,那么这反而是适应灵活需求的客户的。还是那句话,软件本身的复杂性导致的不可避免的结果。