程序员们都知道windows自带的命令行工具是多么的反人类+难用，这么多年过去了，微软终于意识到了这个问题。发布了一个强大的命令行工具，那就是Windows Terminal.

github地址: https://github.com/microsoft/terminal

软件商店地址: https://www.microsoft.com/zh-cn/p/windows-terminal-preview/9n0dx20hk701

NPM是什么？

npm是javascript的包管理工具，类似java生态中的maven, gradle, python的pip。

安装

npm是随同NodeJS一起安装的包管理工具。

NodeJS安装包:https://nodejs.org/en/download/

如果是Mac系统，可以通过brew install node来安装

安装完成后在命令行检查node和npm的版本号

$ node -v
v10.15.3

$ npm -v
6.9.0

由于npm本身更新比node要快，所以可以单独更新npm。

$ npm install npm@latest -g

用法

初始化一个项目:

mkdir npm-demo
cd npm-demo
npm init -y   //生成package.json文件

安装依赖包可以执行下面的命令

$ npm install <package_name>

便可以安装对应的包到执行命令的当前目录，并创建一个node_modules的文件夹,然后把需要安装的安装包下载到里面。

上述命令默认安装的都是最新版本。版本信息会自动记录在package.json中。

$ npm install <package_name> --save  //生产环境依赖

$ npm install <package_name> --save-dev  //开发环境依赖

模块更新

$ npm update

模块卸载

npm uninstall <package_name>

如果要在卸载模块的同时，也将他从package.json文件中移除

$ npm uninstall --save <package_name>

全局包管理

默认情况下，安装的包都是在当前目录。

前端领域目前应用广泛，而前端的基础是JavaScript，学习一门语言，我们首先需要搭建好开发环境，安装好IDE等等。

JavaScript是一门解释性语言，也就是说浏览器就是我们的运行环境了。

目前有名的JavaScript在线编辑器主要是如下几个：

1. jsfiddle
2. jsbin
3. codepen
4. runjs
5. cssdeck
6. jsrun
7. liveweave
8. 菜鸟工具

哪个更好用？

答案: chrome 上面几个我都用过了，各有优缺点，但是都一个共同特点，对于学习js语法来说，都不好用。

关于使用chrome的小技巧：

打开开发者工具–切换到Console Console中可以输入js代码，回车立即执行，如果想输入多行，按住shift+回车即可。

文章来自网络

傻瓜函数式编程

2006年6月19日，星期一

开篇

我们这些码农做事都是很拖拉的。每天例行报到后，先来点咖啡，看看邮件还有RSS订阅的文章。然后翻翻新闻还有那些技术网站上的更新，再过一遍编程论坛口水区里那些无聊的论战。最后从头把这些再看一次以免错过什么精彩的内容。然后就可以吃午饭了。饭饱过后，回来盯着IDE发一会呆，再看看邮箱，再去搞杯咖啡。光阴似箭，可以回家了……

（在被众人鄙视之前）我唯一想说的是，在这些拖拉的日子里总会时不时读到一些不明觉厉 的文章。如果没有打开不应该打开的网站，每隔几天你都可以看到至少一篇这样的东西。它们的共性：难懂，耗时，于是这些文章就慢慢的堆积成山了。很快你就会发现自己已经累积了一堆的收藏链接还有数不清的PDF文件，此时你只希望隐入一个杳无人烟的深山老林里什么也不做，用一年半载好好的消化这些私藏宝贝。当然，我是说最好每天还是能有人来给送吃的顺带帮忙打扫卫生倒垃圾，哇哈哈。

我不知道你都收藏了些什么，我的阅读清单里面相当大部分都是函数式编程相关的东东：基本上是最难啃的。这些文章充斥着无比枯燥的教科书语言，我想就连那些在华尔街浸淫10年以上的大牛都无法搞懂这些函数式编程（简称FP）文章到底在说什么。你可以去花旗集团或者德意志银行找个项目经理来问问1 ：你们为什么要选JMS而不用Erlang？答案基本上是：我认为这个学术用的语言还无法胜任实际应用。可是，现有的一些系统不仅非常复杂还需要满足十分严苛的需求，它们就都是用函数式编程的方法来实现的。这，就说不过去了。

关于FP的文章确实比较难懂，但我不认为一定要搞得那么晦涩。有一些历史原因造成了这种知识断层，可是FP概念本身并不难理解。我希望这篇文章可以成为一个“FP入门指南”，帮助你从指令式编程 走向函数式编程 。先来点咖啡，然后继续读下去。很快你对FP的理解就会让同事们刮目相看了。

什么是函数式编程（Functional Programming，FP）？它从何而来？可以吃吗？倘若它真的像那些鼓吹FP的人说的那么好，为什么实际应用中那么少见？为什么只有那些在读博士的家伙想要用它？而最重要的是，它母亲的怎么就那么难学？那些所谓的closure、continuation，currying，lazy evaluation还有no side effects都是什么东东（译者：本着保留专用术语的原则，此处及下文类似情形均不译）？如果没有那些大学教授的帮忙怎样把它应用到实际工程里去？为什么它和我们熟悉的万能而神圣的指令式编程那么的不一样？

我们很快就会解开这些谜团。刚才我说过实际工程和学术界之间的知识断层是有其历史原因的，那么就先让我来解释一下这个问题。答案，就在接下来的一次公园漫步中：

公园漫步

时间机器启动……我们来到公元前380年，也就是2000多年前的雅典城外。这是一个阳光明媚的久违的春天，柏拉图 和一个帅气的小男仆走在一片橄榄树荫下。他们正准备前往一个学院。天气很好，吃得很饱，渐渐的，两人的谈话转向了哲学。

“你看那两个学生，哪一个更高一些？”，柏拉图小心的选择用字，以便让这个问题更好的引导眼前的这个小男孩。
小男仆望向水池旁边的两个男生，“他们差不多一样高。”。
“‘差不多一样高’是什么意思？”柏拉图问。
“嗯……从这里看来他们是一样高的，但是如果走近一点我肯定能看出差别来。”
柏拉图笑了。他知道这个小孩已经朝他引导的方向走了。“这么说来你的意思是世界上没有什么东西是完全相同的咯？”
思考了一会，小男孩回答：“是的。万物之间都至少有一丁点差别，哪怕我们无法分辨出来。”
说到点子上了！“那你说，如果世界上没有什么东西是完全相等的，你怎么理解‘完全相等’这个概念？”
小男仆看起来很困惑。“这我就不知道了。”

这是人类第一次试图了解数学的本质。柏拉图认为我们所在的世界中，万事万物都是完美模型的一个近似。他同时意识到虽然我们不能感受到完美的模型，但这丝毫不会阻止我们了解完美模型的概念。柏拉图进而得出结论：完美的数学模型只存在于另外一个世界，而因为某种原因我们却可以通过联系着这两个世界的一个纽带来认识这些模型。一个简单的例子就是完美的圆形。没有人见过这样的一个圆，但是我们知道怎样的圆是完美的圆，而且可以用公式把它描述出来。

如此说来，什么是数学呢？为什么可以用数学法则来描述我们的这个宇宙？我们所处的这个世界中万事万物都可以用数学来描述吗？2 数理哲学是一门很复杂的学科。它和其他多数哲学一样，更着重于提出问题而不是给出答案。数学就像拼图一样，很多结论都是这样推导出来的：先是确立一些互不冲突的基础原理，以及一些操作这些原理的规则，然后就可以把这些原理以及规则拼凑起来形成新的更加复杂的规则或是定理了。数学家把这种方法称为“形式系统”或是“演算”。如果你想做的话，可以用形式系统描述俄罗斯方块这个游戏。而事实上，俄罗斯方块这个游戏的实现，只要它正确运行，就是一个形式系统。只不过它以一种不常见的形式表现出来罢了。

如果半人马阿尔法 上有文明存在的话，那里的生物可能无法解读我们的俄罗斯方块形式系统甚至是简单的圆形的形式系统，因为它们感知世界的唯一器官可能只有鼻子（译者：偶的妈你咋知道？）也许它们是无法得知俄罗斯方块的形式系统了，但是它们很有可能知道圆形。它们的圆形我们可能没法解读，因为我们的鼻子没有它们那么灵敏（译者：那狗可以么？）可是只要越过形式系统的表示方式（比如通过使用“超级鼻子”之类的工具来感知这些用味道表示的形式系统，然后使用标准的解码技术把它们翻译成人类能理解的语言），那么任何有足够智力的文明都可以理解这些形式系统的本质。

有意思的是，哪怕宇宙中完全不存在任何文明，类似俄罗斯方块还有圆形这样的形式系统依旧是成立的：只不过没有智慧生物去发现它们而已。这个时候如果忽然一个文明诞生了，那么这些具有智慧的生物就很有可能发现各种各样的形式系统，并且用它们发现的系统去描述各种宇宙法则。不过它们可能不会发现俄罗斯方块这样的形式系统，因为在它们的世界里没有俄罗斯方块这种东西嘛。有很多像俄罗斯方块这样的形式系统是与客观世界无关的，比如说自然数，很难说所有的自然数都与客观世界有关，随便举一个超级大的数，这个数可能就和世界上任何事物无关，因为这个世界可能不是无穷大的。

历史回眸3

再次启动时间机……这次到达的是20世纪30年代，离今天近了很多。无论新 旧 大陆，经济大萧条都造成了巨大的破坏。社会各阶层几乎每一个家庭都深受其害。只有极其少数的几个地方能让人们免于遭受穷困之苦。几乎没有人能够幸运的在这些避难所里度过危机，注意，我说的是几乎没有，还真的有这么些幸运儿，比如说当时普林斯顿大学的数学家们。

web安全策略

web安全对iOS开发者来说重要吗？重要！APP中通常会使用很多web页面，例如广告、登录流程、闪屏，或者需要使用跨平台功能的时候。你可能在页面中仅仅一部分使用web，也可以整个页面都是webView,甚至做一个web app。因此web安全对于app来说非常重要。

来自web的安全攻击有以下几种：

• 跨域攻击
• 预测执行攻击
• 窗口控制攻击

本文将针对这三种攻击类型，给出安全防御措施。

安全传输

网络传输相信大家都很熟悉了，安全的传输能够保证接收到的数据来自可信任的站点，并且在传输工程中不会被篡改。安全传输是其它安全措施的基础，采取的措施包括：

• HTTPS和WSS（webSocket Secure）
• Http Strict Transport Security（HSTS）遵循HTTPS安全协议的web只能访问同样遵循HTTPS安全协议的内容，不能访问遵循HTTP不安全协议的内容。
• Upgrade-Insecure-Requests 请求头中添加这一项表示web支持更加安全的升级机制，服务器可以重定向到这个站点的安全版本。
• 使用cookie确保安全，cookie只能被安全的传输，例如千万不要把cookie放到粘贴板上
• 在app的info.plist文件中 Allow Arbitrary Loads in Web Content 这个开关一定要置为 NO！

跨域封锁

web的内容可以来自任何站点，例如，webView上的一张图片可以来自任何服务器，也可以从任意服务器上加载一个脚本或iframe。需要注意的是要当心来自其它服务器的资源。跨域的保护已经有20多年的历史，并且形成了基本原则–同源策略：只有和页面来源相同的脚本才会被该页面执行。例如iframe来自不同的域名，同源策略不允许加载这个iframe。仅仅靠同源策略还是不够的，还需要采取其它的防御措施。

1. Subresource Integrity

服务器可能会发生异常导致下发错误的资源使得web发生crash，但是开发者通常是知道所要请求哪个资源的，在脚本里面增加一个检查签名。如果签名匹配则认为是下发了正确的资源，如果不匹配仍然可以正常工作，此时尝试从页面的资源里查找或者从自己的服务器重新加载。这样做虽然降低了性能，但是提升了安全性。

<script src="https://cdn.example/framework.js"  
 integrity="sha256-8WqyJLuWKRB...oZkCnxQbWwJVw=">
</script>

window.framwork || // reload from own domain  

2. Content Security Policy

HTTP response：  
:status:200
Content-Security-Policy:  
    default 'self';  // No inline
    script-src cdn.example;
    frame-src social.example;
    frame-ancestors news.example;

HTTP response的Header里面，default设置成自己，默认只能加载同源的资源；script-src和frame-src 分别指定可信任的脚本和iframe的来源；frame-ancestor设置成news.example，指定只有news.example可以iframe我们的web。