之前的博客是在阿里云买的服务器，平均每天将近八毛钱，自从大模型问世之后，写博客的欲望聊胜于无，所以经常很久不更新了，但是感觉每天都付这钱太亏了，所以马年上班第一天把博客迁移到了 GitHub pages，因为迁移的比较随便，所以 1. 博客里面嵌入的代码都乱掉了，不过还好现在有大模型了，也不需要拷贝代码了，所以也懒得整理了，2 就是之前有些博客带图，图还在，但需要一一替换，也懒得弄了，所以图片资源也没有了，3. 就是评论都丢失了，其实之前也没几个评论，也都没啥价值，就没迁移，后续看看还加不加评论框吧，之前一直自建博客，一方面是懒，不想动，另一方面是比较喜欢 inove 这个主题，特此说明。
去年有个时期，国内各大网站纷纷变成了全局灰色，当时说这个事的时候，有同事不知道怎么实现的，认为是设计师重新做了一套 UI，前端程序员紧急上线的，其实并不用，说起来也非常简单，只需要在前端加入如下代码即可： html { -webkit-filter: grayscale(100%); -moz-filter: grayscale(100%); -ms-filter: grayscale(100%); -o-filter: grayscale(100%); filter: grayscale(100%); filter: progid:DXImageTransform.Microsoft.BasicImage(grayscale=1); }
今天不写博客了，水一篇玩玩。老祖宗说，工欲善其事，必先利其器。很多做开发的同学都喜欢 Mac，我也是，自从用了之后爱不释手，但是当帮助一些同学解决问题的时候，总是发现，有些同学的终端使用的是 Mac 自带的终端和 shell，特别难用，完全无法发挥 Mac 的威力，然后给他们推荐怎么配置一下更好用，但是发现很多同学都是，现在已经懒得一个一个同学的说了，所以今天我就写一篇文章，怎么配置更好用的终端和 shell，希望下次再遇到直接能甩给他这篇文章就行。 一. 终端，iterm2 很多同学首先使用的终端是原生终端，那个终端说实话太难用了，我都想不出来理由，这么好用的电脑，苹果是如何忍受这么难用的终端的，这里给大家推荐一个好用的终端：iterm2。官网地址：https://iterm2.com/，GitHub 地址：https://github.com/gnachman/iTerm2，怎么安装这个就不用说了，傻瓜式的。 需要说明的是，安装完成之后，iterm2 默认窗口的大小，个人感觉是有点小的，所以做了一点点修改，希望默认窗口能大一些，修改步骤如下：打开工具 iTerm –> 点击mac左上角的 iTerm2 –> Preferences –> 选择Profiles –> Window –> Settings for New Windows，修改：Columns 和 Rows，个人设置的是 140 和 36，感觉还行，然后关闭，重新打开iTerm。就可以看到你更改后的效果。 二. shell，Oh My Zsh shell 是什么，我也不想解释了，大家可以自己搜索，另外如果想查看自己电脑有几种 shell，可以使用如下命令： cat /etc/shells 在 Linux 系统里执行这个命令和 Mac 略有不同，你会发现 Mac 多了一个 zsh，也就是说，mac 为用户预装了个 zsh。不过由于早期配置过于复杂，无人问津，很多人跑来看看 zsh 的配置指南，二话不说扭头就走了。直到有一天，国外有个穷极无聊的程序员开发出了一个能够让你快速上手的 zsh 项目，叫做：oh my zsh，官网地址：https://ohmyz.sh/，Github 地址是：https://github.com/ohmyzsh/ohmyzsh 使它的配置一下子简单起来了，下面就简单说说这个 Oh My Zsh。 安装，就一步： 由于目前系统的默认 Shell 都是 bash（可以通过：echo $SHELL 查看），所以需要使用如下命令修改当前用户使用 zsh： ...
做技术转眼很多年了，也参与过很多系统的开发了，见过各种同事写的 error message，在我看来有些是非常典型的程序员思维，自己感觉一点问题都没，孰不知用户一头雾水，每次提出修改的时候，有些人还振振有词改不了，我提出自己修改意见之后，还有人说不行，前几天和我们半路出家的产品经理聊这个问题，今天闲来无事写一篇文章简单总结一下自己的想法，供大家讨论。 首先开宗明义：个人认为 error messge，不仅是提示用户为什么报错，他遇到了什么问题，而且是告诉用户如何解决他遇到的这个问题，所以个人最好的 error message 应该具备以下要素： 准确 这个不是废话吗？如果不准确，甚至是误导，这 error message 不仅不能解决问题，还添乱，所以这个应该是第一位的，切记一定要准确，没有做不到，那就和没有 error message 没啥区别，甚至不如不提示，毕竟这样不提示不会让人误入歧路。 简明扼要 说到的是简明扼要，我们大家都知道注册的时候那一大串协议吧，你有认真看完吗？哪次不是拉到最后然后点击同意？当然谁也不会把 error message 写那么复杂，在此仅是举个例子而已，大家记得一定要简明扼要，能一句话说明白的就不要两句话。多说一句，注册的协议写那么一大串也是没办法的事，谁可以一句话把注册协议写明白？任何人都做不到，此时就是以准确为先了。 在前两个要素的基础上：提示用户为什么报错以及解决方案 个人以为这个才是最优秀的 error message，告诉用户为什么报错，这个其实不是必须的，但是很多时候告诉用户原因不会让用户迷惑，还是应该的，这个等下再举例说明。告诉用户解决方案，个人以为这个才是最核心的，当用户拿到这个解决方案的时候：不用任何思考，他不需要任何思考，只需要按照解决方案一步一步的做，就可以完美解决他的问题。之前看过的一篇文章，说乔布斯可以一秒钟把自己变成傻子，我认为是同理的，这才是真正做产品的思路，把自己当成傻子想象傻子怎么解决问题，所以做产品的时候就想象如果给傻子写 error message，告诉傻子解决方案，让他一步一步照做就可以解决问题，所以错误的提示的时候就把用户当成傻子，这样写出来的错误提示一般不会有大问题。 提示为什么报错 个人以为这个提示没错，但很多时候是有问题，唯一没有问题的时候，就是对于一些简单的问题可以告诉用户原因，但必须保证用户一看到原因就知道解决方案是什么，举个例子，表单提交，提示某某字段为空，用户一看就知道解决方案原来是这个字段不可以为空，填上就好了，所以这个告诉用户原因没问题，但是有些东西，用户拿到原因并不知道怎么解决，例如之前同事做的一个验车的时候遇到的问题，error message 提示：订单 ID 为空，这个提示有错吗？没有错，这就是典型的程序员的思维，原因就是这个，我找不到订单，就获取不到订单 ID，然后不能往下走，所以报了这个错。但是这确实是有问题的，用户拿到这个原因有啥用，他能找到订单吗？他不能，然后他知道怎么找到订单吗？也不知道。所以当时看到这个问题之后，我就力推优化这个提示，然后当时一堆同事说：没有办法优化。我当时就说为什么不能优化？同事都说，因为就是找不到订单。然后我就问：那让用户找某某某，怎么解决的，最后我力排众议，连产品经理反对也不管了，反正我是程序员，我能决定代码怎么写，就得按照我的想法来写。最后改成了告诉用户解决方案：请先联系客服绑定订单。然后看到这个解决方案他们就知道了怎么做了，而不是像以前那样遇到这个问题，就找到开发咋回事，然后开发再说你找某某某，然后某某某在告诉用户你找客服绑定订单，终于就再也没有用户因为这个问题来找我了，我也终于感到可以清闲一会了，那个某某某也可以轻松一会了。这就是典型的告诉用户原因，一堆人脑子转不过来弯的例子。 最后再说一下，前面说的一个问题如果只告诉用户解决方案呢？这个确实能解决用户的问题，但是个人以为有些时候用户会迷惑。举例就是：假设用户在支付的时候，如果余额不足，你不告诉用户原因，而是直接告诉用户不能用此支付方式，用户换个支付方式也能解决问题，但是用户会迷惑：为什么我不能用这个支付方式，需要换一个？最后用户也许自己能发现原因，但是用户可能会一试再试，因为用户不一定一定会听你的，所以你可以告诉用户余额不足，请换个支付方式支付，这个时候用户既知道了原因，又有了解决方案，可以更快速的解决问题。所以综上所述，个人认为最好的 error message 应该是： 在准确简明扼要的基础上：告诉用户原因以及解决方案，其次是告诉用户解决方案，再次是告诉用户原因，当做一个东西的时候，千万不要局限于程序员思维，多站在用户的角度上想想，而且一定要把用户当成傻瓜，当一个傻瓜用你的系统的时候，你的这个 error message 能不能帮他解决问题，如果不能，就说明不能说明有错，但一定说明还有优化的空间。 最后的最后，想说也许这么文章看起来很乱，但意思肯定表单的很清楚，如果你按照这篇文章的指导思想去写 error message，不敢多说，但一定会让用户感觉你的系统易用性提高了十倍，入门简单了十倍。
这个问题其实不能称之为问题，给服务器命名应该算是一个常识性问题，任何人都可以想到的，其实不仅是服务器，在我们生活中的一切都有名字，如果我们生活在一个没有名字的世界中，你想想有多可怕把？但为什么写这篇文章呢？因为我们公司很奇怪，不知道是运维疏忽还是啥，每次通过跳板机登陆线上服务器，必须通过 IP 地址才行，所以每个人一定要记录自己负责的服务器的 IP 地址才可以，否则一筹莫展，但是 IP 地址，大家都懂得，不然也不会有域名的存在了，大家都通过 IP 访问互联网就好了，前几天看公众号，刚好看到知书堂有位老师写过一篇文章来说这个问题，所以转载过来，供大家给服务器命名参考，后续也会给出我自己的小建议。原文如下： 这个问题太简单，以致于提起来，很多人忽略掉了。今天给大家秀一下这几年见到的命名情况，供大家赏玩。 这里面没有最好，但有最差。我们按命名满分 5分来打分。 第一位：无敌的localhost 提起这个大家不会陌生，REHL 系例安装默认的名字就是：localhost 很多学习环境里都是: localhost 很多测试环境里也是: localhost 几十台上线机器所是: localhost 爷，你真的无敌了。 不举例子了。使用这个命名的。只能说 I 服了 YOU，你离误操作也不远了。 命名评分：0 分。显然没毕业，建议学习去。 第二名：业务 + 编号 使用业务命加编号，如：user01、user02、。。。 命名评分：3 分。属于有规模管理想法，会减少一些误操作。全局管理上还有一定的局限性 第三名：业务 + 角色 + 编号 如：core-master-1、core-master-2、core-slave-1、core-slave-2 非常直观，但对于机器好象不能允许随便切来切去，只能在几台机器里面切换了。在传统企业或是中小企业里，这种命名结构见的比较多。 命名评分：3分。中小规模命名规则，不适合自动化环境。 第四名：工程派命名 先分测试库uat-业务名-编号、预上线库puat-业务名-编号、生产库prod-业务名-编号 这个命名有点Oracle教课书的感觉，估计系统里分区也是/u01之类的。 评份：4 分+ ，多给一分怕骄傲。就这样吧。 第五名：有规范的命名 机器的命名，原业务名 + IP（点用下划线替代）+ 机房简写，如：userdb_192_168_11_100_cs prod.系统类型.机房.ip，如：prod.v.cs.192.168.11.100 其中V表示虚机。 机房+IP，如：cs19216811100 使用IP地址做服务器的命名，有多个IP使用重要的IP命名。 在终端提示上也可以显示IP提示，这一块形式也比较多。 评分：5分。推荐 整体上来说这种命名结构属于比较严禁的结构，从命名上基本很容易判断这台机器是做什么的。 其它 Tips： 机器命名，其实没有好坏之分，原则上让在CMDB及监控系统里容易标识出来即可。 对于登录系统，也可以考虑利用/etc/motd 把该机器上跑的业务显示出来。 同时可以利用登录执行相关文件如：/etc/profile 把系统里的关键东西显示出来，如：当前该机器运行几个MySQL，端口号是什么、当前内存使用情况、当前磁盘使用情况 原文完 对于上面知书堂老师给出的命名方案最后一种，也是他认为最好的，但是我个人还是感觉有一些问题，例如首先从这台机器看不出是属于哪个团队的，这对于有多个团队的公司来说，不方便，也看不出角色等等，而对于 IP 地址很多时候我个人是不关心的，我只需要能登录到这台机器，并且无论研发运维都很好记即可，如果我已经连 IP 地址都记得了，那么我还记其他的干嘛，直接用 IP 登陆不就好了吗？ ...
最近 Facebook 开源的 React 的开源协议专利条款一事闹得沸沸扬扬，著名的 WordPress、百度等纷纷声明弃用 React，最终 Facebook 听从大众的声音改回了BSD，这就牵涉到一个如何选择开源协议的问题，因为 React 是一个生态，所以这事影响比较大，其实之前有很多关于开源协议用错导致原作者利益受损的事，例如前两个月就有一个被雷军称赞的称为最牛的 00 的 CEO 的公司抄袭别人代码连素材都不修改的案例，所以想到之前曾看到有一个乌克兰程序员 Paul Miller 制作了一张图，一分钟明白你应该选择哪个开源协议，原图如下： 原文地址：http://paulmillr.com/posts/simple-description-of-popular-software-licenses/ 如果英文不好的话（其实我英文更不好，但连猜带蒙也看了个差不多），有热心网友翻译了一个中文版，地址：http://blog.csdn.net/wadefelix/article/details/6384317 多说一点： 记得刚实习的时候，老大强调不准使用任何未经公司批准的任何软件，如果需要必须报备，经相关人员同意后方可使用，当时不明白为什么，其实看看 GPL 协议也就猜到了。另外刚开始玩 GitHub 的时候，以为就随便把代码放上去就完事了，当然代码写的很烂也不会被人使用，但严格意义上来说还是应该选择一个开源协议的，据说 GitHub 目前有相当数量的项目没有添加开源协议，所以为了使开发者养成选择开源许可证的习惯，GitHub 现在在创建新库的表单中添加了一个许可证选项。该选项中提供了一组简化的开源许可证，开发者选择后，Github 会自动在其库的根目录中创建一个 LICENSE 文件。 最后为了维护开源社区的健康发展，同时不致自己的利益受损，大家一定注意选择合适的开源协议。