笔记本

简介 Homebrew 是一款自由及开放源代码的软件包管理系统，用以简化 macOS 系统上的软件安装过程。每个操作系统都有类似的，比如 Ubuntu 的 apt，Centos 的 yum。 常用命令 安装 brew ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)" 使用brew安装软件 $ brew install git 使用brew卸载软件 $ brew uninstall git 使用brew查询软件 有时候，你不知道你安装的软件的名字， 那么你需要先搜索下, 查到包的名字。 brew search /wge*/ 其他brew命令 brew list 列出已安装的软件 brew update 更新brew brew home 用浏览器打开brew的官方网站 brew info 显示软件信息 brew deps 显示包依赖 brew upgarde 更新所有 brew upgarde [包名] 更新指定包 brew cleanup 清理所有包的旧版本 brew cleanup [包名] 清理指定包的旧版本 brew cleanup -n 查看可清理的旧版本包，不执行实际操作 卸载 brew cd `brew --prefix` rm -rf Cellar brew prune rm `git ls-files` rm -r Library/Homebrew Library/Aliases Library/Formula Library/Contributions rm -rf ....

2018已经结束了，总结自己这一年来就是三个角色的转变：自己从一个学生成为了一个社会人，从一个读者变成了一个自媒体人，从一个在校学习者变成了终身学习者。 每一种角色的转变意味着责任的转变，每多一种角色，就会多承担一份责任。角色变得越大，责任也会承担得越大，当然收获得也更大。 技术成长 对于技术成长，我感觉我莫名其妙的就走在了前端的前沿，刚刚在知乎上看到一个帖子2019 前端技术规划该包含什么？很多大佬在规划里面都谈到 Rxjs、Typescript、函数式编程、Flutter、PWA、Node 相关, 然而事实就是这么巧(或者可以说我眼界比较远，偷笑)，在 2018 年我很多都已经接触过了，比如 Rxjs、TS、函数式编程、Node 等。 聊 Typescript(TS) 特别是对于 TS，我在公众号，然后我维护的微信群里早就已经说过，TS 最近会火起来的，没学的赶紧学起来，不知道有多少人听了我的，看了那么多大佬的规划，我更加的坚信了 TS 将会变成未来前端工程师一项必备的技能。 然后对于 TS 的学习，我看过这些东西，我推荐一下，不过对于 TS 我仍然是个初学者，不敢说有多精通，我只在我自己的小项目中用过，没有在公司的项目中使用。 TS 官方文档 技术胖的 ts 教程 TypeScript极速完全进阶指南 深入理解 TypeScript 如果问我使用 TS 感觉是什么样的，我只能说相逢恨晚，就跟 vim 一样，用过之后就像一直用。 聊 Rxjs 对于学 Rxjs 来说，我想说的是，Rxjs 是我学过最难学的一个库了，目前为止没有之一。现在回想起来，要是早点接触函数式编程就好了，如果先是研究函数式编程，再去学习 Rxjs，我相信会轻松 40% 以上。但是目前为止，我并没有拿到真正的生产环境去用过，只是写过一些简单的 demo，然后看过一些资料和书籍，同时也在团队做过相关的普及。 Rxjs 难的就是思维方式以及 api 很多，然后就是由于一些概念不知道为什么要这么设计(很多思想我相信学了函数式编程就会明白了)。 对于 rxjs 的学习看过很多的文章，我这里还是推荐三个我觉得比较全的学习资料。 Rxjs 官网 30 天精通 Rxjs 程墨老师的深入浅出 Rxjs 聊函数式编程 学习函数式编程给我最大的感受就是让我拓宽了我的眼界，突然的就弥补了以前知识体系缺的点。比如对于 compose、curry 这些 js 里面也算一直提及的重要概念，但是总是记了又忘，忘了又记，就算自己手写来实现过了，但是隔了几个月还是又忘了，因为没用过。但是学了函数式编程以后，发现全是这些东西，compose 呀、柯里化呀、部分应用呀，就跟用数组的 map、reduce 这些方法那么熟练，所以，现在闭着眼睛也能写出来，就几行代码的事儿。...

compose 实现 function compose(...args) { return (result) => { return args.reduceRight((result, fn) => { return fn(result) }, result) } } pipe 实现 function compose(...args) { return (result) => { return args.reduce((result, fn) => { return fn(result) }, result) } } 柯里化实现 function currying(fn, ...args) { if (args.length >= fn.length) { return fn(...args) } return function (...args2) { return currying(fn, ...args, ...args2) } } 部分应用实现 function partial(fn, ...args) { return (..._arg) => { return fn(....

现在互联网发达的时代，大家都会有很多的群，xxx 交流群、xxx 技术交流、xxx开发群、xxx技术学习群等，大家的初心可能都是想交流的，遇到点问题然后就可以在群里问。 然而很多时候你问的问题没人回答；也有时候问了半天还是没找到答案；也有时候当你把问题发出来了，别人正准备回答你的时候，你说知道了；然后刚开始群里很活跃，慢慢的就死了。 其实以上问题，都是大家不想看到的，然而在群里提问是我们加入群的初心，但是很多人做不好，最终导致你的问题无人解答，群慢慢的失去意义。 今天我所谈的就是群里提问的艺术，让你的问题快速得到解决。 我将今天的问题分成以下三部分进行介绍： 提问之前 提问之时，怎么提问 注意事项 提问之前 在群里提问之前首先我们应该做好功课，看自己是否完成以下步骤，否则你的提问将一塌糊涂，大概率得不到想要 的答案。 尝试自己解决 不能自己解决应该准备的哪些 尝试自己解决 尝试自己解决是非常重要的一步，这也是我们能否经过这个问题能够成长的关键所在。 通过搜索引擎搜索：baidu 或者 google(推荐)，搜索结果中前三页如果找不到你想要的信息，就进行下一步吧。对于成熟的开源项目，你遇到的问题，很可能别人也遇到过。这时通过 Google、StackOverflow 等网站的搜索服务，可以帮你快速定位并解决问题。永远记住，地球上的你并不孤单，包括你遇到的问题。 **查阅手册/文档：**确保自己阅读过至少一次官方文档。这样在遇到问题时，如果能回忆起只言片语，就可以再去读一遍相关文档，问题往往也就解决了。 **查阅社区/论坛：**阅读常见问题文件（FAQ）或者开源项目的 issue，或者论坛(类似 react china) **询问朋友：**如果你使用的开源软件，在朋友圈或同事圈里也有人使用，那么抬起你的脚、或拿起你的电话，真挚诚恳的探讨不会遭遇拒绝，而会增进友谊。不要犹豫，你的内心渴望面对面交流，你的朋友也是。 **自检并不断测试：**试自己检查或试验以找到答案。 **阅读源码(这步非必须)：**如果你是程序开发者，尽量尝试阅读源码以找到答案。 经过以上 6 步或者 5 步你都无法解决遇到的问题，那么你确实针对这个问题能力有限，准备去群里请教了，那么在尝试自己解决之后无果，应该做哪些准备呢？ 不能自己解决应该准备的哪些 一定要明白自己想要问什么问题：不能自己都说不清自己想要问什么问题，那么群里提问你也问不出什么来。 梳理准备您的问题：要说明之前你都干了些什么。 要用言简意赅的语言：这个是我们作为职场一个必备的技能，说重点，言简意赅。 怎么提问 抱着平和对等的心态，找到合适的途径后，就得静下心来将遇到的问题写成文字。书写文字不是一件简单的事情，我们可以从遵循一些简单的规则开始。 用词准确，问题明确 标题要简洁清晰，要言之有物。 Bad：救命呀/急/跪求，遇到了一个 react 问题，xxx 组件渲染不出来 Good：在使用 xxx 版本的 react ，我操作了 xxx，也写了 xxx，但是 xxx 组件渲染不出来 一个好标题范例是目标 —— 差异式的描述，许多技术支持组织就是这样做的。在目标部分指出是哪一个或哪一组东西有问题，在差异部分则描述与期望的行为不一致的地方。 描述清晰，信息充足 **准确有效的信息：**描述事实，而不是猜测，如果你想给出你的猜测，一定要先描述事实，给你的猜测一些证据，不然就不要猜测。 **问题表现/内容：**按照时间顺序列出问题症状。问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如 20 行）记录会非常有帮助。 **简单的做过什么尝试：**在描述你做过什么尝试的时候，简单的你描述你做了哪些尝试就行，为什么要这么做其实不是那么重要。 如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。 经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。 玉伯有句话是这么说的： 提问者选择的路本身就是一条崎岖之路，对于要解决的问题，实际上有更好的方式。这种情况下，描述清楚目标，讲清楚要干什么非常重要。...

今天的文章是来自 medium 的一篇文章，点赞数有将近 1 万 9，所以翻译出来给大家分享一下，有些概念怕大家不了解，所以我放了一些 维基百科的解释。如果有翻译得不是很好的地方，请看原文：https://hackernoon.com/top-12-things-that-destroy-developer-productivity-2ddf0abc190 正文： 很多文章都涉及技术主管和项目经理的角色。我们经常遇到的一个共同主题是如何提高团队的工作效率。但是在你集中精力来提高生产力之前，你可能首先要考虑是什么在摧毁它，以便建立一个可靠的基础。不幸的是，即使 Peopleware 近 30 年前发布，我们也看到许多团队在一些（消极的）显着方式中遭受巨大的生产力损失！ 没有人希望程序员在没有计算机的情况下完成工作，但是有很多公司希望程序员能够在不知情的情况下完成工作。这同样不切实际。 因此，让我们深入探讨我们的 12 个阻止您的开发人员“进入区域”并提高工作效率的事项列表。我将尝试从大多数到最不具影响力的列表中优先考虑此列表。随意评论！ 如果您想知道这一切是否值得投资，只需考虑开发商的工资。生产力提高10％甚至更多！ 中断和会议 在我看来，中断是开发人员的首要生产力杀手。开发人员在中断之前不能轻易回到他们正确的位置。他们需要进入发展的思维模式，然后慢慢追溯到他们离开的地方。这可能需要超过30分钟。中断越多，挫折越多，工作质量越差，错误就越多 - 而且还在继续。 “The more times you trip me up while I’m trying to get started — the longer between each time I’m going to try. If you fill my morning with interruptions — don’t be surprised when the day is unproductive.。” –A developer on Reddit 大概意思就是说，每次被打断都要重新开始，如果你的一天里经常被打断，那么当你一天没有任何成果的时候，不要感到惊讶。 会议怎么样？会议和中断之间的唯一区别是会议是计划中断，这会使情况变得更糟。如果开发人员在处理任务时知道他们会中断，则他们无法完成任务。因此，如果他们在一两个小时内召开会议，他们将无法取得任何进展，因为大多数工程任务需要更多时间。 As Paul Graham wrote, “A single meeting can blow a whole afternoon by breaking it into two pieces, each too small to do anything hard in....