[2020/03/02 V1.1.1]
更新：
- 支持新功能：应用图标
- 支持选择应用，你可以不用手动填写应用路径了
- 添加中英文双语支持
详细：
- 主界面
支持应用图标的显示
- 添加应用Add App
- 现在你可以不用手动填写应用路径了，点击按钮Choose App会打开文件选择对话框，然后找到你所需要的应用，应用图标也会一并显示在界面上
- 现在你可以不用手动填写应用路径了，点击按钮Choose App会打开文件选择对话框，然后找到你所需要的应用，应用图标也会一并显示在界面上
Visual Studio Code的设计亮点
本文转自网络，原文网址 https://zhuanlan.zhihu.com/p/35303567
Visual Studio Code（VS Code）近年来获得了爆炸式增长，成为广大开发者工具库中的必备神器。它作为一个开源项目，也吸引了无数第三方开发者和终端用户，成为顶尖开源项目之一。它在功能上做到了够用，体验上做到了好用，更在拥有海量插件的情况下做到了简洁流畅，实属难能可贵。
我是VS Code用户，同时也为它开发插件，插件市场里的众多Java插件基本都是我们团队的作品，所以我在日常工作中观察到不少VS Code在工程方面的亮点，下面就来逐一探讨。
简洁而聚焦的产品定位，贯穿始终
你知道VS Code的开发团队人数不多吗？难以相信吧，大家都觉得VS Code无所不能，如此强大的工具那么几个人怎么做得出来。实际上功能丰富是个美好的错觉，因为大部分针对特定编程语言和技术的功能都是第三方插件提供的，VS Code的核心始终非常精简，这很考验产品团队的拿捏能力：做多了，臃肿，人手也不够；做少了，太弱，没人用。他们团队选择了专注于核心功能的开发，为用户提供简洁流畅的体验，并将该思路贯穿在产品开发的每个环节。在我看来，这就是第一个亮点。 Continue reading “Visual Studio Code的设计亮点”
Pdf Comparer 一个比较Pdf内容的工具
因工作需要最近正在开发一个比较Pdf内容的工具，趁着还记得一些思路来简谈一下这个工具的设计。当然实事求是的说，其中有一些设计可以再优化，但是“懒”这个字限制了我。闲话不多说，首先让我们来看一下这个工具的类图：
一个查找到指定文件然后进行删除的工具
上上个周末，Maybe，记不清了，也许是上上上个周末，总之那会儿我在听英语，但那其实就是催眠曲，反正很快就靠着椅子睡着了。而后很自然地做起了美梦，梦里却为那台办公笔记本电脑犯着愁，为啥愁？磁盘空间又满了，是完完整整地满了，1B都插不进去的那种。为了释放出可怜的磁盘空间，哪怕一点点，这1年里，可谓想了不少招数，这次似乎真的无计可施了。那该怎么办？一觉被吓醒。
眯着眼睛想了想，也许是有些文件很大，或许可以找到它们，删除一些来释放一些空间。
于是乎坐起来，趁着阳光还不错，便写了这个工具。它主要提供以下功能：
- 输入字符串去搜索符合文件名规则的文件
- 输入文件大小去搜索大于该Size的文件
- 查找的结果会被保存在SQLite数据库中
- 可以暂停查找，也可以继续
- 对查找结果可以再进行排序，方便二次筛选
- 选中某些查找结果进行删除操作
- 如果在查找和删除的过程中发生了异常，比如资源被占用而无法删除，可以通过Messages窗口查看
之前发布的工具很少去写文字来表达设计上的优势和缺点，以后可能会多写一些设计思路。这个工具在设计时，主要考虑了以下问题：
- 由于针对文件系统的操作通常是比较消耗计算机资源的，所以考虑了暂停功能，这样当需要优先在其它应用下操作时，可以先暂停
- 有的时候我们会查找出大量的文件需要去甄选，可能一时半会儿难以做完，所以考虑了将查找的结果保存到SQLite数据库中，这样下次可以直接打开上次的查找结果继续甄选
- 为了面向更多的操作系统，核心的代码都基于.Net Standard编写，这意味着可以方便地运行在多种操作系统上（当前仅表示层使用WinForm实现）
- 考虑只是个简单的工具，Layer的划分比较简单随意，但在设计时独立了Business Layer，也解除了对DA的依赖，为未来可能的独立化该组件提供捷径。
- 考虑查找的过滤条件未来可能会继续增加，抽象了过滤条件组合，能够很方便添加新的过滤规则
新年前最后一弹，发布一个抽奖工具
在正式开始介绍这个工具之前，先来讲一下这个工具的历史吧，唉，又勾起满满的回忆：）
它的第一个版本，如果没有记错的话，应该诞生在2010年冬天，记得当时所在公司的驻地是苏大冠名的一家科技产业园，产业园公司邀请所有园内企业参加那年的年终Party，晚会过程中会穿插抽奖环节，由于产业园里很多企业是做IT有关的产品与服务，所以希望抽奖环节能否弃用传统的抽奖箱方式，于是乎基于友情赞助，便写了这个工具的第一个版本。
紧接着下来的第二年，一个朋友向我要了这个工具，还提了一个新需求，能不能添加一个作弊功能，简单来说就是让某人必中某等奖，另外由于人员名单是现场签到输入，界面会被同时显示在投影仪上，所以作弊并不太方便，进而希望能不能作弊不被人看见？于是乎，便又增加了一个基于WML语言编写的WAP网站（因为那时候手机都支持WML，支持HTML的智能手机还并不多），以让作弊者使用手机来操作某人必中某等奖。该功能在现在的版本中，已经被拿掉，作弊实在太猥琐。
前几天机缘巧合之下，听说某公司会进行一场旧产品内部拍卖，于是想起了这个工具，便从尘封多年的笔记本中找出了源代码，顺便也升了个级。
好了，故事说完，谈正事，先说说工具大概提供的功能吧：
- 支持2种数据库，SQL Server和SQL CE，默认使用的是SQL CE，程序在首次运行时会自动创建数据库结构
- 自定义奖品名称，也就是一等奖，二等奖啥的
- 新建或修改一场抽奖活动，能够编辑此次活动包含哪些奖品和数量，以及允许指定每个人最多允许中奖几次（通常设置为1，即这个人中奖1次后，在这场活动中便不会再中奖）
- 单条输入或批量导入这场活动有哪些人参加，也就是说只有这些人可以参与抽奖
- 进行抽奖：
- 这批抽几个（假设三等奖100个，在抽奖时可以输入这批只抽20个）
- 从本场活动的人员名单中随机抽取
- 领奖，将人员勾选中以表示此人已经领取了奖品
发布一个新工具Ping，兼年终总结
这篇文章只是草稿，后面应该会有增减。
一年一年又一年，转眼就快到新年。
好长时间没有写日志了，也许是懒了，也许是事情太多，总之理由是可以找出一堆一堆又一堆的。回想一下设计模式系列已经很久没有更新了，记得当初是打算每个月写一篇的，汗颜啊。
写这篇日志有两个目的，一是最近写了个小工具，用来测试主机是否在线的；二是想对过去一年作一个简单的总结。
先来总结吧，这里只说好的，只说知识技能上的成长，不说坏的，也不说情感金钱之类的。当然不是没有坏的，相反，而是坏的实在太多了，不敢列，不想列，担心会抽自己几巴掌。
- 复习了TypeScript，PowerShell， Bash，Python，C++等编程语言，虽然说离开软件行业已近2年，但是你懂的，有一种习惯叫兴趣，也有一种工作方式叫痛并快乐着。下面分别简单说一下这几种语言：
- TypeScript是微软开发的面向对象的脚本语言，支持鼓励强类型编程，实现了ECMAScript 标准，可以轻松编译出Javascript代码，从而运行在Javascript引擎上。当下很多流行的UI框架都有推荐使用TypeScript作为开发语言，比如Angular 2, Vue, Dojo等，但是随着Javascript版本的不断更新，以及相关引擎的支持，似乎越来越不需要TypeScript了。
- PowerShell是微软开发的Windows下的Shell脚本语言，我个人认为它的最大一个特点是可以使用.Net Framework，并且它也拥有通常高级语言所包含的语法（它的语法也比Bat要优雅的多，站在我的角度我优先会使用PowerShell而不是Bat，除非环境有所限制），所以理论上它可以实现任意功能。
- Bash是很多Linux系统上的默认Shell环境，它拥有比较完整的编程语言语法系统。个人认为，如果想利用好Linux系统，简化繁琐的工作，那么Bash是必修的课程。
- Python，说起这个语言，就我个人而言很是曲折，最早接触它的时候，2.3版本才刚刚发布，谁曾想到现在它会这么火爆，拥有丰富的API、工具、框架。想拿高薪，你得会Python，毕竟在Big Data, Cloud, AI等领域它最为抢眼。
- C++，整个人生道路上，我学的第一门语言就是它（不是C，我直接自学的C++），虽然从来没有正式地使用它做过项目，但实事求是的讲，在后来整个工作学习的道路上，它不断的启发着我，这次因为工作的原因，又重新温习了一遍，感叹前人真是牛逼。
- PLC。我他么也没想到，以前一个搞软件的，会去学习PLC，只能解释成博爱吧。关于PLC，我顶多算入了个门，简单一句话，它还是挺有意思的。不过我想随着技术的不断发展，基于Linux等平台的高级语言编程才是大势，比如基于Andorid，Windows loT等，另外像西门子这么贵的PLC设备也终就会被Raspberry Pi这种小巧便宜的设备所取代。
- 英语。说到这个，虽然说到了痛点，但是比去年还是有了些进步，偶尔讲两句也可以。
好吧，总结就总结到这里，后面如果想起了别的再加上来。下面来说说最近写的一个小工具。
工具的名称叫Ping，顾名思义，和我们经常使用的命令Ping有着相似的功能，即发送ICMP数据包给指定主机，来侦测远端主机是否在线，判断与远端主机之间的网络连接状况等。这个工具的特别之处是可以批量侦测大量主机，结合多线程来快速诊断网络状况。并且该工具基于.Net Core编写，所以能够跨平台运行，无论是Windows、Linux还是MacOS。下面的截图基于Debian 9.5 + .Net Core 2.1。 Continue reading “发布一个新工具Ping，兼年终总结”
一个自动保存邮件附件的服务
刚到这个工厂工作的时候，这个工厂的一个应用需要将某个发件人发来的邮件中的附件保存在指定的目录下，以便另外一个服务去指定目录下读取这个附件。不过有一个问题是这个应用一直运行的不是很稳定，有的时候它并不能将附件正确保存，并且占用资源较大，后来也引起了一个生产问题。在后来的某个空闲的时刻，便写了这样一个windows service，目前该服务已经稳定运行三月有余，它具有以下功能：
- 支持多个邮箱账号
- 支持将邮箱中某个文件夹下的附件保存到指定位置
- 支持2种收邮件的协议：POP3和IMAP，以及支持SSL传输
- 如果某个邮件附件已经保存，会将该邮件标记为已读
由于是windows service，它没有UI界面，直接来看一下它的config file. Continue reading “一个自动保存邮件附件的服务”
B1 Xml Firing 一个极速解决B1iSN daily issue的工具
这是怎样的一个工具？这是一个极速解决你99.99% B1iSN daily issues的工具，会极大的提高你的工作效率。说实话，如果不考虑业务上的限制，这个工具，理论上可以操作任何B1数据。
我们知道在B1iSN的日常问题处理中，作为一个系统集成平台，B1iSN基本上就是将数据从源系统集成到目标系统中。在B1iSN中，通过XML来描述源系统与目标系统的数据转换，下面是一个B1iSN的XML消息实例。 Continue reading “B1 Xml Firing 一个极速解决B1iSN daily issue的工具”
File Name Length, 检查文件路径长度的小工具
之所以当时写这个小工具的目的，就是为了解决一些由某些软件生成的文件路径过长（尤其印象深刻的是npm中的资源嵌套），同时由于Windows系统的限制，这些文件可能无法被另外的一些应用所访问，所以就想通过这个小工具来预先检测出那些超过系统限制的文件，然后再逐步解决问题。
Tips: 在Windows系统中，目录名长度要小于248字符（最多247个字符），包括盘符“D:\”（3个字符），目录和目录之间“\”（1个字符，目录和文件之间的“\”不算长度），再加上文件名必须小于260字符（最多259个字符，目录名短，文件名就可以长，目录名长，文件名就要短，总共两者加在一起要小于260个字符）
这个小工具有以下几个功能：
- 较高的性能，IO访问一直是软件开发中的一个需要注意的性能瓶颈，为了克服这个问题，在这个小工具中，能够通过自定义线程数来提升访问IO的并发性能（建议可以设置成与CPU的核心数相同，超线程可以*2）
- 结果窗口会反馈满足条件的文件路径和当前长度
这个小工具的界面如下：
- 主界面
- Submit，选择文件夹路径
- 点击OK，开始处理
Compactor 批量压缩小工具
在发表这个小工具之前，先说一段小故事。当年在某公司的软件框架组里，每当有新的Release要发布时，总是要将很多Components分别打包压缩上传（每个Component皆是独立的功能组件），实在是烦之又烦，于是乎狠心之下写了这样一个批量打包的工具。它具有以下几个功能：
- 支持按文件夹分别压缩打包（每个顶层文件夹会被压缩成一个压缩包，当然也可选择只生成一个压缩包）
- 支持两种压缩格式（7z和zip）
- 支持三种压缩级别（Normal, Fast 快但压缩比低, High 慢但压缩比高）
下面是操作界面：
- 假设现在的目录结构如下，我们需要将b、c两个文件夹分别压缩给不同的客户，并且还需要将b、c两个文件夹压缩在一起作个备份。
- 打开小工具主界面（原计划还要再添加几个其它独立功能，所以主界面上当时就设计成一个大大的打开Compactor的按钮）
- Compactor的主界面
- 需要打包的文件夹目录
- 选择需要打包的子目录
- 选择打包方式（每个子目录压缩成一个压缩包，还是所有子目录放在一起压缩成一个压缩包）
- 选择压缩包文件存放目录
- 选择压缩包文件格式（7z, zip）
- 选择压缩比
- 生成压缩包
- 生成压缩包，弹出处理信息
- 这是当选择将所有文件夹压缩在一个压缩包中的界面
- 最后，文件夹中的结果
