首先我们要在客户端（本机）生成密钥对 这里的密钥对是 Public key，具体请参考 公开密钥加密 使用命令 1ssh-keygen -t rsa 接下来会提示让你输入一个路径来保存密钥对，默认在 ~/.ssh/id_rsa 下面生成 id_rsa（私钥）和 id_rsa.pub（公钥），如果没什么特殊需求就直接默认就好。 然后提示你输入密码（即本机使用 SSH 连接时的密码 #和服务器密码

吾辈发布了一个油猴脚本，可以直接安装 解除网页限制 以获得更好的使用体验。 场景在浏览网页时经常会出现的一件事，当吾辈想要复制，突然发现复制好像没用了？（知乎禁止转载的文章）亦或者是复制的最后多出了一点内容（简书），或者干脆直接不能选中了（360doc）。粘贴时也有可能发现一直粘贴不了（支付宝登录）。 问题欲先制敌，必先惑敌。想要解除复制粘贴的限制，就必须要清楚它们是如何实现的。不管如何，浏览

场景 如果你是一位开发者，可以看一下另一篇博客 使用 GreaseMonkey 解除网页复制粘贴限制。或许，你能找到更好的方式 登录支付宝时突然发现密码框不能 C-V 粘贴，也无法使用右键了。提示说是为了安全，实际上不就是为了让人使用 App 扫码么。。。想尽办法为难 PC 用户，这次 Chrome 的强制复制插件也没能起到作用。然而不管其是如何实现禁用粘贴/禁用右键的，但其一定需要用到 Jav

场景由于 electron 应用分为主进程、渲染进程，所以它们之间需要通信。而 electron 本身实现了一个简单的 event emitter 通信模型，虽然能用，但并不足够好。 参考: https://www.electronjs.org/docs/api/ipc-renderer 问题 基于字符串和约定进行通信本质上和当下前后端通信差不多，没有利用同构优势 使用起来没有任何限制，意味

场景 吾辈是一只在飞向太阳的萤火虫 JavaScript 中的数组是一个相当泛用性的数据结构，能当数组，元组，队列，栈进行操作，更好的是 JavaScript 提供了很多原生的高阶函数，便于我们对数组整体操作。然而，JavaScript 中的高阶函数仍有缺陷 – 异步！当你把它们放在一起使用时，就会感觉到这种问题的所在。 例如现在，有一组 id，我们要根据 id 获取到远端服务器 id 对应的值

场景有时候需要与其他程序进行交互时，自定义协议是一个不错的选择 – 它能在程序为启动时启动程序然后处理其它程序的动作，而这是其它解决方案，包括 HTTP 请求、共享数据库不能比的。其实日常生活中也有现成的例子，迅雷的自定义协议下载链接、BitTorrent 协议、百度网盘启动本地客户端等等。 使用 参考: 将当前可执行文件设置为协议的默认处理程序（注册表级别） 让程序保持单例启动 设置客户端支

距离提出离职已然过去三周了，但现在仍未找到合适的工作。也不是没有面试过，但确实没有找到合适的 – 对于吾辈而言，合适指的是优秀的 team，最好是平台而非业务 team。 吾辈也找到了一些大佬帮忙内推，包括 快手 基础平台建设 百度 YY 直播 腾讯 微众银行 阿里云 DataV 数据可视化 但最让吾辈感觉难过的不是面试之后因为能力不足而失败，而是即便内推也仍然没有面试的机会。当然吾辈也能理解

当今世界上不同国家社会和国民文化中的犬儒主义可以分为两大类:公开的犬儒主义和戴面具的犬儒主义。它们的基本区别在于,当一个人因为犬儒主义而不相信统治意识形态、制度、权威、信仰体系以及由权力或习俗规定和主导的法律或价值规范时,尤其是怀疑和鄙视政府、政治权力和政治人物的时候,公开的犬儒主义会在公共言论和行为中表示出来,而戴面具的犬儒主义则通常不会,不仅不会表示不相信,而且还会假装成相信的样子。公开的犬

场景有时候我们需要在主进程和渲染层共享某些数据，而 electron ipc 通信 显然更适合传递消息而不适合共享数据。 相关依赖事实上，我们这个需求已经有人考虑过了，例如 electron-store 就已经实现了可以在渲染层、主进程均可使用。 is-electron: 判断是否 electron 环境 electron-store: 在 electron 应用中存储数据 那么，我们直接用

技术栈 electron: 跨平台桌面开发 react: 视图层框架 typescript: 强类型的 js lerna: 前端 monorepo 管理工具 yarn: 包管理器，workspace 与 lerna 搭配非常好 create-react-app: react 官方出品的 react 脚手架生成器，社区和活跃度都不是其它工具可比的 其他依赖库 参考: 前端资源管理 rollup

场景最近在生产环境遇到了下面这样一个场景：后台在字典表中存储了一些之前需要前后端共同维护的枚举值，并提供根据 type/id 获取字典的 API。所以在渲染列表的时候，有很多列表的字段直接就是字典的 id，而没有经过后台的数据拼装。 也是吾辈之前写的文章 react 通用列表组件封装 中的那个通用列表在实际使用时遇到的问题之一。 起初，吾辈解决问题的流程如下 确定字典字段，添加转换后的对象类

场景 之前吾辈也在 SF 上询问过 类似的问题。 目前在实际业务中遇到了两种情况 程序的功能在分发给不同组织使用的时候有所差异，即不同的组织都会存在一些定制化的功能。最常见的差异例如 表单的字段存在差异 列表展示的字段与相关操作有所不同 组件内的代码在某个权限下才会执行，但是又依赖于组件内的一些状态，如何将这些代码分割到不同的地方（例如不同的文件）便于之后的维护。 一些按钮在指定权限下存在