官网：https://molunerfinn.com/PicGo/index.html

前言

作为一个比较常用markdown写文章、博客的人，在markdown里插入图片对我而言一直一个比较繁琐的活。以前每周写电影推荐的时候，我要在markdown里插入一张电影海报，我需要如下的操作：

1. 打开豆瓣的网站，选一张满意的海报，下载
2. 打开七牛的网站，登录，点点点，找到上传，上传
3. 关闭上传窗口，找到地址，复制地址，再关闭七牛
4. 粘贴到markdown里

每次都需要繁琐的打开网页进行一些必要而枯燥的操作。这样很麻烦。在用过mac上一款很不错的小工具应用iPic后我非常喜欢它的简洁操作。不过它免费版本并不支持七牛图床。所以我就想着，能不能自己写一个类似的工具呢？结合自己的使用习惯再顺便加点功能。

于是我就开始自己的图片上传工具的开发了。它叫做PicGo。

<!-- more -->

技术选型

最早最早我想着用swift来写一个原生的应用，主要想着能做出体积友良、性能优秀的应用。不过鉴于swift迭代的太快，很多教程都已经不适合了。并且swift网上的教程对我这个小前端来说着实要学的东西不少。我只是想做个方便自己的工具而已，一切以方便自己作为大前提。作为一个前端工程师，我决定采用electron来开发。同时因为我是Vue的粉丝，一并就使用了electron-vue作为我的electron开发脚手架。不得不说，electron-vue提供的脚手架做的真的很用心，而且我自己要做修改加配置什么的也很方便。日后做跨平台支持的话也比较容易。

需求分析

由于用过iPic，很多它的一些操作模式我觉得特别值得借鉴。比如我想要个简单的拖拽就能实现上传，我想要能够上传我剪贴板的图片，我想要是实现上传成功后自动复制链接到剪贴板，这样我就可以直接编辑了。

那么这样一来，我编辑文章只需要如下操作：

• 找到要上传的图片，使用这个工具直接上传
• 上传成功后自动复制地址到剪贴板，在markdown里直接粘贴

一下子省去了很多原本繁琐的操作！

功能展示

前前后后，用每天的闲暇时间从0开始学习electron框架，到Travis-ci构建出第一个可用的版本，大概花了一个月的时间。基本实现了我自己当初的目标，极大提升了我自己的文章写作体验。

操作演示

精致设计

macOS系统下，支持拖拽至menubar图标实现上传。menubar app 窗口显示最新上传的5张图片以及剪贴板里的图片。点击图片自动将上传的链接复制到剪贴板。

便捷管理

查看你的上传记录，重复使用更方便。支持点击图片大图查看。支持删除图片（仅本地记录），让界面更加干净。

可选图床

目前支持微博图床和七牛图床。未来将支持更多。方便不同图床的上传需求。

多样链接

支持4种剪贴板链接格式，让你的文本编辑游刃有余。

后续工作

目前PicGo还是一个很年轻的项目，bug肯定是不少的，功能方面也有所欠缺。所以还需要不断地完善。我希望大家在使用的过程中有什么意见或者建议都可以在项目仓库里的issues里提出来~

• 目前暂不支持Windows和linux，未来将会逐步支持。
• 未来将支持更多的图床。如果可能，可以支持自定义的图床（只要设定好协议）
• 将集成系统服务，提供一键上传的全局快捷键
• 提升用户体验，修bug

最后

希望这是一个能够提升你文章编辑体验的工具。如果你想学习electron开发，我也会在不久之后写几篇文章用于记录我是如何开发PicGo这个electron应用的。如果你喜欢它，欢迎给这个项目点个Star。另外，它是开源免费的，如果你觉得它对你有所帮助，也可以考虑给我打赏一杯喝咖啡的钱~

支付宝打赏：

微信打赏：

都说使用react angular 等前端框架实现的站点不能很好的SEO，这种是真的存在的吗？如何提升SEO呢

我们是一家致力于为人工智能企业提供数据结构化服务的初创企业，坐标深圳南山科技园。 AI驱动企业，有机会接触领先的人工智能技术；创业初期，发展空间大，诚招猿大神、猿小神、潜力猿！

Web前端工程师 8K-15K + 期权

岗位描述： 根据产品和项目设计，负责PC端、移动端、微信公众号等页面的前端美化； 根据业务需求，编写相应的前端组件和模块； 设计和编写一些具有挑战性的前端交互控件；

职位要求： 熟练掌握HTML5、CSS3、JavaScript等 熟悉W3C标准与ES6规范，掌握Promise、Rxjs、async、await等异步编程模型 熟练掌握CSS盒模型、常用布局以及浏览器和移动设备兼容性 熟悉Canvas/SVG等Web绘图API 熟练使用至少一种JS框架，能独立开发常用组件，熟悉Angular（非AngularJS）优先考虑 熟练使用各种调试、抓包工具，能独立分析、解决和归纳问题 熟悉typescript语言是一个很大的加分项 了解混合应用开发框架，如React Native、ionic等，优先考虑

node.js后端研发工程师 15K-25K + 期权

岗位描述：

1. 负责公司web平台的REST接口和数据库架构设计，支持高并发、大流量服务的快速响应；
2. 负责部分后端功能模块和中间件的设计与开发；
3. 完善Oauth后端用户认证机制和安全防护。

职位要求：

1. 计算机及相关专业本科以上学历；
2. 一年以上node.js开发经验，熟练掌握node异步模式；
3. 掌握至少一种node.js后端框架，如express、koa；
4. 掌握Promise、Rxjs、async/await等异步编程模型；
5. 熟悉Oauth认证机制，有Oauth2.0服务架构设计经验者优先考虑；
6. 熟悉至少一种其他后端语言：Python/JAVA/C#/Go等；
7. 熟悉常用数据库，Mysql、Mongodb、Redis等；
8. 有typescript和前端经验优先考虑；

简历投放地址： leewayzhang@sparkapi.ai

原文地址: http://www.jianshu.com/p/963a9d146da7

前言

Android 官方架构组件在今年 5 月份 Google I/O 大会上被公布, 直到 11 月份一直都是测试版, 由于工作比较繁忙, 期间我只是看过类似的文章, 但没有在实际项目中使用过, 更没有看过源码, 所以对这几个组件的使用很是生疏, 同时也觉得这几个组件非常高大上, 非常神秘!

直到 11 月份 Android 官方架构组件正式版发布, 并且 Google 也在 Support Library v26.1.0以后的版本中内嵌了 Android 官方架构组件中的生命周期组件, 我想, 这是趋势, 既然 Google 这么推崇, 那我也是时候学习一波并将它们引入 MVPArms框架了

Github : 你的 Star 是我坚持的动力 ✊

简单介绍

因为想将 Android 官方架构组件引入 MVPArms框架之中, 所以我认真学习了 Android 官方架构组件中除了 Room之外的所有源码, 以考察是否整个组件都适合引入 MVPArms框架

在学习完源码过后, 发现 Android 官方架构组件其实并没有想象的那么高深, 原理反而是我们在日常开发中都会用到的知识点, 那我就在文章的开头先简单的介绍下 Android 官方架构组件中的这几个组件

Lifecycles

生命周期组件是 Android 官方架构组件中的核心组件, 它可以使各种实例作为观察者与 Activity和 Fragment等具有生命周期特性的组件绑定在一起, LiveData和 ViewModel都是基于此组件, 简而言之就是, 你将需要绑定生命周期的实例注册给该组件, 该组件就会在你指定的某个生命周期方法执行时通知这个实例

应用场景很多, 比如之前在 MVP架构中, 你需要在 Activity执行 onCreate时, 让 Presenter初始化一些操作, 这时就不用在 Activity的 onCreate中再调用 Presenter的某个初始化方法了, 直接使用官方的生命周期组件即可完成, 在 Activity执行 onDestroy时需要释放一些对象的资源, 也可以使用到生命周期组件

LiveData

LiveData具有两个功能, 第一个功能是观察者模式, 在 Value发生变化时通知之前注册的所有观察者, 第二功能是基于生命周期组件与 Activity和 Fragment等具有生命周期特性的组件绑定在一起, 在生命周期发生改变时停止或恢复之前的事件

简而言之就是, 当某个页面请求网络数据成功后需要同步 UI, 但这个页面已经不可见, 这时就会停止同步 UI的操作

ViewModel

ViewModel有两个功能, 第一个功能可以使 ViewModel以及 ViewModel中的数据在屏幕旋转或配置更改引起的 Activity重建时存活下来, 重建后数据可继续使用, 第二个功能可以帮助开发者轻易实现 Fragment与 Fragment之间, Activity与 Fragment之间的通讯以及共享数据

浅析官方架构组件

用法就不多说了, 此类文章和 Demo太多了, 明白了它们的功能和应用场景后, 我们才知道它们是否真的适合自己的需求, 而不是盲目跟风, 下面我就来分析下我是如何考察新技术, 以及如何判断这些新技术是否有必要应用到自己的项目中

Lifecycles

上面介绍了生命周期组件的功能, 这里就来分析一下生命周期组件是否有必要引入我的框架 MVPArms

说到生命周期我就想到了我之前在 传统MVP用在项目中是真的方便还是累赘?中讨论的一个内容

现在市面上流行的 MVP架构有两种, 第一种是将 Activity 或 Fragment 作为 View, 抽象一个 Presenter 层出来, 第二种是将 Activity 或 Fragment 作为 Presenter, 抽象一个 View 层出来

第一种类型代表的框架有 MVPArms, 第二种类型代表的框架有 TheMVP, 当然第一种类型的 MVP架构在市面上用的是最多的, 那么第二种类型的优点是什么呢?

我在上面这篇文章也说过, 主要优势有两个, 方便重用View, 以及 可直接与 Activity 或 Fragment 的生命周期做绑定, 这样就可以直接使用 Activity 或 Fragment 的生命周期, 不用再去做多余的回调, 当然也有缺点, 我在文章中也有介绍, 有兴趣的可以去看看

第一种类型的 MVP架构是不具有可以和 Activity或 Fragment的生命周期直接做绑定的优势的, 所以很是嫉妒第二种类型的 MVP架构, 这也是两种类型的 MVP架构最大的区别, 但你想的没错, 现在使用生命周期组件就可以使第一种类型的 MVP架构很轻易的具有绑定生命周期的优势, 现在第一种类型的 MVP架构将如虎添翼

经过以上的分析, 我认为生命周期组件对于我的框架来说是很有必要的, 这将使日常开发更加便捷

LiveData

LiveData与 RxJava都是基于观察者模式, 功能上也有重合, Google 在官方文档上也明确表示, 如果你正在使用 RxJava, Agera等类似功能的库, 只要你能正确的处理数据流的生命周期, 就完全可以继续使用它们来替代 LiveData

Note: If you are already using a library like RxJava or Agera, you can continue using them instead of LiveData. But when you use them or other approaches, make sure you are handling the lifecycle properly such that your data streams pause when the related LifecycleOwner is stopped and the streams are destroyed when the LifecycleOwner is destroyed. You can also add the android.arch.lifecycle:reactivestreams artifact to use LiveData with another reactive streams library (for example, RxJava2).

从官方文档可以看出 Google 对此的建议就是 RxJava, Agera, LiveData等类似功能的库, 你只使用一个即可

选择 RxJava 还是 LiveData ?

LiveData和 RxJava的功能的确过于重合, 我也十分赞同 Google 官方的建议, 两者之中选择其一就可以了, 没必要两者都引入项目, 而 MVPArms框架, 也正好引入了 RxJava, 所以我也来分析分析在 MVPArms框架中该选择 LiveData还是 RxJava?

于是我认真的研究了其源码, LiveData具有两个功能, 通知观察者更新数据和根据生命周期停止和恢复之前的事件, 而 Rxjava加上 RxLifecycle, RxJava加上 AutoDispose, 或 Rxjava加上生命周期组件, 也可以轻易做到根据生命周期停止和恢复之前的事件, 在配上 Rxjava强大的操作符, LiveData能做的事 RxJava都能做, LiveData不能做的事 RxJava也能做

并且 RxJava不仅仅只是 RxJava, 他还是一个庞大的生态链, 他还有 RxCache, RxLifecycle, RxAndroid, RxPermission, Retrofit-Adapter等大量并且强大的衍生库, 我们离开它做很多事都非常不便, 刚刚出生, 羽翼未丰的 LiveData相比于 RxJava将没有任何优势, 甚至显得非常简陋

因此 LiveData和 RxJava之间如果只能选择一个的话, 我没有任何理由选择 LiveData

ViewModel

ViewModel中有一个功能让我十分惊艳, 也十分好奇, 它可以使 ViewModel以及 ViewModel中的数据在屏幕旋转或配置更改引起的 Activity重建时存活下来, 重建后数据可继续使用, 这个功能十分实用且十分重要, 因为之前也没有一个官方解决方案, 所以我觉得很有必要将这个功能引入 MVPArms框架

同样另外一个功能, 它还可以帮助开发者轻易实现 Fragment与 Fragment之间, Activity与 Fragment之间的通讯以及共享数据, 同样也正是我所需要的官方解决方案

但在我继续深入研究, 准备将它引入到项目中时, 却发现 Google 将这个功能做了高度封装并限制了它的使用范围, 只能用于 ViewModel

但我想 Google 既然能让 MVVM框架中的 ViewModel具有这些功能, 那我为什么不能将这个功能扩展出来提供给 MVP框架中的 Presenter, 乃至其他更多的模块?

于是我认真的研究了其源码, 准备通过修改源码并封装成库的方式, 让更多的开发者在更多的场景下能够使用到这些功能

改造 ViewModel 组件

要想改造 ViewModel 组件自然要对它的整个源码分析一遍, 知道其原理, 才知道如何下手

分析源码

篇幅有限, 就来简单的分析下源码把, 源码其实也就几个类, 经过了层层封装, 核心代码就在一个叫做 HolderFragment的 Fragment中,

在我看来 ViewModel 组件的核心原理也就是 HolderFragment中的一行代码实现的:

setRetainInstance(true);

setRetainInstance(boolean)是 Fragment中的一个方法, 我想很多人应该都知道这个方法的意义

简单来说将这个方法设置为 true 就可以使当前 Fragment在 Activity重建时存活下来, 如果不设置或者设置为 false, 当前 Fragment会在 Activity重建时同样发生重建, 以至于被新建的对象所替代

意思是只要将这个方法设置为 true, Fragment以及 Fragment之中的所有数据都会在 Activity重建时存活下来

这时我们在 setRetainInstance(boolean)为 true 的 Fragment中放一个专门用于存储 ViewModel的 Map, 自然 Map中所有的 ViewModel都会幸免于 Activity重建

于是我们让 Activity, Fragment都绑定一个这样的 Fragment, 将 ViewModel存放到这个 Fragment的 Map中, ViewModel 组件就这样实现了

如何改造

想要知道如何改造, 那我们就要明确这次改造的最终目的是什么, 我们的目的就是要让 ViewModel 组件能用于 Presenter, 乃至其他更多的模块, 不止是用于 ViewModel

那为什么 Google 官方的 ViewModel 组件不能用于其他模块呢, 通过阅读源码可以知道, 是因为 Google把上文提到的 Map, 封装了起来, 并没有提供出去, 并且限制了 ViewModel的构建方式

ViewModel 组件让一个新的 ViewModel必须继承于它的基类, 并且让开发者必须提供一个 Factory指明当前 ViewModel的构建方式, ViewModel 组件会在合适的时机, 主动去根据 Factory构建 ViewModel实例, 并放入 Map中

这时整个构建过程都被 ViewModel 组件掌控并被限制于 ViewModel, 所以我需要做的就是将 Map和 ViewModel的构建方式扩展出来, 将更多的控制权交给外部的开发者

实践

经过上面的分析, 思路和方案都有了, 接下来就剩下如何把思路和方案实现了

于是我结合上文分析的思路和方案对官方源码进行了改造并做了适当的优化, LifecycleModel就这样诞生了

这篇文章主要还是讲在完成一个目标前, 在从 0 到 1 期间进行的思路和分析的过程, 至于细节你如果感兴趣的话还是去看我的源码把, 哈哈, 注释很详细哦!

Github : 你的 Star 是我坚持的动力 ✊

总结

一个新技术是否真的适合自己还是需要自己去考察, 不应该盲目跟风, 如果你只知道这个技术很火然后去用它, 不知道为什么用它, 用它的好处, 那你就会一直陷入被动学习的窘境, 一直在学习, 但是总觉得自己跟不上时代的进步, 担惊受怕, 这是现代技术人大部分都存在的处境

至于最近闹的沸沸扬扬的简书 饱醉豚事件, 自从简书 CEO站台后, 已经不再是当事人一个人的事, 而是关乎到简书整个平台, 既然这个 CEO这么傲气, 这个平台都不在乎我们这个群体, 我们也不再去关注这个平台就是了, 流量是跟着原创作者走还是跟着平台, 自己心里没点逼数吗?

简书以及简书 CEO最好做出深刻的道歉, 否则我也会离开简书 (好像我更文频率也不是很高把? 咳咳… 我主打的是质量! 质量! 不是数量, 逃～)

踩坑

在实际项目中使用 ViewModel 组件时我也遇到了一些问题, 浪费了我很多时间, 所以有必要分享出来让大家少走弯路

通过 Activity 获取 ViewModel 时遇到的坑:

• 在 Application.ActivityLifecycleCallbacks 中的 onActivityCreated 方法中获取 ViewModel 时, Activity 每重建一次, 获取的 ViewModel 都是重新构建后的新实例, 并不能让 ViewModel 以及 ViewModel 中的数据幸免于 Activity 重建, 所以不要此方法中获取 ViewModel

• 在 Activity 的 onDestroy 方法中不能获取 ViewModel, 会报错

通过 Fragment 获取 ViewModel 时遇到的坑:

• 在 FragmentManager.FragmentLifecycleCallbacks 中的 onFragmentAttached 方法中获取 ViewModel 时也会出现和 Activity 一样的情况, 获取的 ViewModel 是重新构建后的新实例, ViewModel 以及 ViewModel 中的数据不能幸免于 Activity 重建, 所以也不要此方法中获取 ViewModel

• 在 FragmentManager.FragmentLifecycleCallbacks 中的 onFragmentDestroyed 方法中也不能获取 ViewModel, 会报错

• 在 Fragment 的 onDestroy 方法中不能获取 ViewModel, 会报错

Hello 我叫Jessyan,如果您喜欢我的文章,可以在以下平台关注我

• GitHub: https://github.com/JessYanCoding
• 掘金: https://gold.xitu.io/user/57a9dbd9165abd0061714613
• 简书: http://www.jianshu.com/u/1d0c0bc634db
• 微博: http://weibo.com/u/1786262517

– The end

NODEJS express能向header中添加自定义字段吗。 res.setHeader(“key”,“name”);没有效果

刚融资，有一定前景~欢迎敲窗

岗位要求：

• 有 electron / nwjs + vue 研发经验

• 二年以上 JavaScript/Node.js 开发经验，JavaScript 基础扎实，熟悉 ES6 规范
• 掌握 Http 协议，熟悉 Koa, Express 等概念以及相关 WEB 开发框架，了解异步模式、事件循环
• 熟悉 W3C 标准，熟练使用 HTML、CSS、Javascript 等前端语言
• 熟练跨浏览器、跨终端的开发，了解 hybrid 相关技术（ react native，weex 等）
• 熟练使用 jQuery，Bootstrap，Vue，React 等主流前端库或框架；
• 具有较强的业务能力，沟通能力，分析和解决问题的能力
• 计算机科学或相关专业毕业

加分项：

1. 参与开源项目 or 对开源社区有贡献
2. 熟悉任意一门服务端语言 如 Java、PHP、Python 等
3. 熟悉 Node.js 并且有实践经验
4. 关注新事物、新技术，有较强的学习能力，喜欢挑战

岗位职责：

1.负责开发桌面端程序

联系邮箱： zhaopin@yanshi.in

一直卡在minutes进度不动了，百度谷歌都搜了没有解决答案，官文文档没看到这个问题，至在是没招就来这儿提问了，下载的是社区版

本来不想回复的，匿名的那哥们写的挺好的，虽然不懂他为什么要匿名。但看到某些回复，不得不说几句。乱解读，误人子弟的事，还是有必要澄清的，以免Node有无端被黑，相信这也是所有布道者都应该承担这种除魔卫道的责任。

没有领袖，Node 之父用 Go，TJ 也用 Go，都跑了。

1. 语言不是因素，是他想做的事儿变了，但他的心依然还是爱着Koa

TJ转做Go有很多原因

• 人家做的基于aws Lambda的基础设施 https://github.com/apex/apex，选择Go无可厚非，从架构角度，我还要给他点赞！
• TJ对Node.js一直很关注，尤其对Koa框架，看他的Pinned repositories 就知道，另外给Koa提issue被他怼过，也可见他很在意Koa

别乱解读，误人子弟

1. Node.js之父在2012年就离开社区的，然而这5年发展的依然很好

狼叔写过一篇文章 请别拿“死”人做文章， Node.js之父Ryan Dahl在2012年就离开社区的，我们必须要承认他作为创始人的伟大创举，但不能标签化，ryan不代表node，从他离开社区后，对于社区而言，他就“死”在曾经的丰功伟绩上，未来与他无关！

Node.js之父在2012年就离开社区的，然而这5年发展的依然很好，并无影响。这篇文章本来没什么问题，但有些人借位营销就恶心了。

狼叔说：Node.js不是最好，也不是最差，是性价比比较高的，可惜node做后端一直不温不火，java，php利益相关，只有新项目用，微服务架构下，会更好一些。很多人node是用错的，不是用node就什么都用，分清场景。不误解，不传谣，合适自己的才是最好的 但是总有些人想拿这事儿做文章过度解读，

抽象程度不够高，对于做业务的人来说这很痛苦。使用者中小白太多，人员素质参差不齐，包的数量多，质量却呵呵。

这完全是没逻辑的屁话，看起来没问题，却经不起推敲。

抽象程度，所有语言都有这个问题，Go就没有么？Java、PHP这么多年小白少么？说人员素质参差不齐，哪个语言不一样？所以说，这完全是狗屁逻辑。我比较喜欢Ruby社区，是高手和低手两级分化最明显。Node.js从2009年到现在才8年，再成熟能成熟到哪里呢？不拿一个起点比较都是扯淡。

最后说npm，黑的完全不到点上，目前超过60万个模块，绝对是社区第一。在众多包管理器上，我没见过质量都一样好的，按照8020原则，60万里至少有12万个模块是不错的吧，你工作中能用到的会超过三位数么？

所以说质量好不好要看人怎么选，而不应该赖到npm上。长点心吧。

用来做脚本倒是没啥问题，做商业开发就处处踩坑了。我没怎么用 Node做 Web，因为怕 hold 不住。

没用过，就别瞎逼逼。

国内国外的成功案例，眼瞎看不到么？我亲历的去哪儿和阿里都在大量使用，我亲耳听到的腾讯大量使用Node，对于李成银所在的360团队也是大量使用。

如果说 Node hold 不住，其他语言就能 hold 住？呵呵

如果说 人 hold 不住，那我相信，那是水平问题。

目前 Node Web 框架依然是 koa 和 express 类似的架构，中间件没什么问题，但是如何组织它们，如何在 high level 层面把控他们却没有看到很好的最佳实践。

没用Node还哔哔框架，不是打脸么？

我们可以根据框架的特性进行分类

各种框架都经过大厂小厂实践，别的语言实现的我敢说Node都有了。还有什么所谓的更好实践，从2005年rails横空出世之后，大部分框架都是借鉴ROR，Node就算没有走到最前面，至少没有落后于最佳实践，否则，请给出，否则，请闭嘴，别瞎逼逼。

大公司也是相继开发自己基于 koa 的框架。

悖论，去哪儿的基于Express用的杠杠的，无任何问题。Node不缺Web框架，Koa虽好，但迁移各种还需要时间，未来是变化的，Koa能否一统天下还犹未可知。可以肯定的是Koa在异步流程控制做的改进，命名为Node下一个Web框架是不过分的。

比如micro，比如fastify，非常多好东西。

不过在我一个 Rails 使用者的眼里，这些框架还是不够 high level如果性能要求高，我的选择肯定是 Go 而不是 Node。

用rails的人还考虑性能么？我不是黑ror的朋友们。rails这样的神器足够好，即使ruby以前性能那么不好，但不影响人家开发很多世界级应用啊。尽管后面有的被替换了，但又怎样呢？做ror的高手技能都非常全面，ruby和前端和运维都是极其的熟练。当然Node和go也有这样的人，但普遍偏弱，这不是人的问题，而是产生的时间较短，没背景的人就不能出现全栈牛逼的能力。

如果真追求性能，我建议用rust写，如果还想牛逼，用c写，最好顺便把操作系统也写了。

人还是要有自知之明，做应用软件和系统软件是不一样的思维。傻逼才只看性能呢。

Node 除了亲 JS 好像对我没啥吸引力。但是如果公司非要用我也不反对，大不了自己摸爬滚打找出最佳实践即可。

没用过，请绕过。我特别尊重苏千和朴灵，推动Node在阿里落地，比如苏千做的cnpm真是功德无量，比如Egg，能够统一全公司的资源去推动框架落地，可预见大公司阻力。朴灵的alinode解决了性能调优的问题，内部使用的经验沉淀，对外提供付费服务。

这是人物。做的比说的多，低调如此，也不去惹是非。用德艺双馨形容不为过。

Node 还有一个好处是 UI 做的好，比如 pm2，比如调试器，毕竟是前端，但这些都不是杀手级的卖点呀。我不是挑语言的开发者。

Node 和 UI有关系么？呵呵呵

Node 对我属于一个可用可不用位置。不过相信牛逼的你肯定可以玩转 Node。加油吧少年。我对Node新人的建议是玩一玩可以，

没用过，就别瞎逼逼。

js已经横跨3端，pc/h5，移动端（hybrid和组件化），pc client（nw.js和electron，atom和vscode体验还不错）

Node补足了js服务端的补足，比如io，比如过于依赖浏览器。

• 1）初衷，server端，不想成了前端开发的基础设施
• 2）命令行辅助工具，甚至可以是运维
• 3）移动端：cordova，pc端：nw.js和electron
• 4）组件化，构建，代理
• 5）架构，前后端分离、api proxy
• 6）性能优化、反爬虫与爬虫
• 1. 全栈最便捷之路

不过要早点转 Go，因为 Node 并没有什么突出的优势。

Go在服务器端，并发模型上确实很好。做后端是极好的选型。但在前后端分离或者单体应用里，真的合适么？

前面说了，性能并不是继续选型的唯一因素，不然ror那些牛人早转了。我一直的看法是前端离不开node，api层node有优势，io密集和脚本动态，做api组装聚合类的非常合适。对于后端服务，Node也是可以的，不过这时的node和go是一样的，尤其是上了微服务架构，服务是独立的，和语言无关，按照其特性选就好了，何必扯一些没用的。

最后说一下Node全栈

每次演讲我会都问大家是不是前端，回答“是”的人非常多，我会开玩笑的恭喜大家：“现在的前端就是钱端”，确实，现在前端发展异常的快，而且没有趋向于类比java里ssh框架的那种稳定，所以未来很长一段时间，还会增长，持续混乱，这对前端来说是把双刃剑，一方面有很强的压迫感，不学习就跟不上时代，另一方它也是机遇，能够带给更多机会，包括money。

大家都疑惑的一个问题是如何在这样巨变的时代能够通过学习来应变，我可以很负责的告诉大家，没有捷径，但通过掌握 Node.js 能够让你降低这个学习曲线而已，毕竟Node.js是大前端的基础设施。大家可以看一下，前端的开发过程，模块化，构建，辅助工具，调优，架构调整，可以说Node.js是无处不在的。

其实，辅助大前端开发只是Node.js的一个非常无心插柳的衍生功能，通过掌握Node.js能够让你能做的更多、获得的更多，甚至可以说有更多自我实现的快乐，在后面的章节会详细讲解Node.js的具体应用场景好处，这也是本书名字里“更了不起的”要去阐述的内容。

综上种种，就是我一直提倡以 JavaScript 语言为中心的 Node全栈概念的缘由，JavaScript 覆盖所有前端，Node.js 擅长做 I/O 密集型的后端，外加辅助开发的各种基础设施，无疑是工作、学习和成为快速掌握全栈技术最好的途径。你会的越多，你能做的就更多，你的人生也将会有不一样的精彩篇章。

补充

没有领袖？

笑死了，根本就是外行，Node的接力棒是 TJ 和 sindresorhus ？ryan走了， Isaac Schlueter接✋的好么，然后是TJ Fontaine。之后闹出了iojs分裂问题，后来促使joyent不得不妥协，成立Node基金会。 现在是纯社区玩法，背后是Node基金会。

可以说，任何人离开都不会有特别大影响。铁打的营盘流水的兵，而已。

TJ是想对Node改进的，但Node的负担太重了，现有体系和机制改变不是易事，而且也没有动力促使它改变。很多特性都是意淫的，根本不是Node设计的场景，所以说这些没意义。响马大哥的fibjs就是一个不错的实践，但为什么二者不融合呢？。。。。因为没法真的没法这样做。。。

拿 express 和 Rails 对比，是一样东西么？

我知道不能把 Node 跟 Rails 一起比，因为一个是平台，一个是框架。那我就详细拿 express 和Rails 比吧。express 可以说是提供了一个 RESTful API + MVC 的框架，本身既没有 orm 也没有提供各方面的脚手架（对比 Rails 的 scaffold）也没有提供任何主观性的集成（比如你需要自己搭建测试框架）

进一步暴漏无知。express本身只是内核加了几个实用中间价的微型框架。Rails呢？是一个一站式的顶级Web框架。rails在2005年横空出世，node是2009年产生，exprss是2010年才有，这个比较客观么？

谬误1:express 可以说是提供了一个 RESTful API + MVC 的框架

a）谁说express是RESTful API了？

明显要自己规约才能实现的，这也意淫到express上。。。sinatra呢，beego，Revel，Martini呢？

express上实现rest可以，但不能这叫。

var express = require('express');
var router = express.Router();

var $ = require('../controllers/users_controller');

// -- custom

/**
 * Auto generate RESTful url routes.
 *
 * URL routes:
 *
 *  GET    /users[/]        => user.list()
 *  GET    /users/new       => user.new()
 *  GET    /users/:id       => user.show()
 *  GET    /users/:id/edit  => user.edit()
 *  POST   /users[/]        => user.create()
 *  PATCH  /users/:id       => user.update()
 *  DELETE /users/:id       => user.destroy()
 *
 */

router.get('/new', $.new);  
router.get('/:id/edit', $.edit);

router.route('/')
  .get($.list)
  .post($.create);

router.route('/:id')
  .patch($.update)
  .get($.show)
  .delete($.destroy);


module.exports = router;

b）谁说express是MVC了？

express目录有router和view就算mvc了？呵呵，看看rails，thinkjs，eggjs行么？

├── app.js
├── bin
│   └── www
├── package.json
├── public
│   ├── images
│   ├── javascripts
│   └── stylesheets
│       └── style.css
├── routes
│   ├── index.js
│   └── users.js
└── views
    ├── error.jade
    ├── index.jade
    └── layout.jade

7 directories, 9 files

c）谁说express是和rails一样的框架了？

你可以这也理解express只是内核（插件机制） + 几个常用插件。是一个麻雀虽小，五脏俱全的微型框架。一个连基本约定，orm，脚手架，migrate都没有的框架也算框架？

express不会直接使用的。大部分情况都是要自己封装的，如果说直接拿express-generator做事儿，做分析的，那真是用浅尝辄止形容不为过。

d）说express不如rails

确实不如，本来就不是一样的东西。ruby诞生自93年，rails诞生2005年，node和express呢？

起点不一样，比较有意义么？

Node哲学 与 Left-pad事件始末，真了解？

Node 社区的哲学是可以把 left pad 作为一个包，这看起来真的很傻。

明明不知道事件始末就乱发表意见，是否得当？是够傻的。

2016年3月份，kik是Azer写的模块，但Kik同时是手机通信录的社交软件，所以这个社交软件上就无耻的直接说让Azer把kik名字给他们，Azer不同意，他们就拿律师函恐吓，并让npm妥协，所以npm就妥协了

Azer一怒之下将自己在 npm 上的 273 个封包全部撤下，其中就包括 left-pad 封包。一石激起千层浪，依赖 left-pad 的上千个项目包括 babel 和 react-native 瞬间崩溃。大量开发者看着自己项目构建失败，顿时被吓尿。

观点

• 1）就没见过这么傻逼的公司，一个红包就能解决的事儿，非要用强权，如果对方在改模块上耗费心血少的话，转给你也是可以商量的。

• 2）11行代码要不要封装成一个包？

sindresorhus: Containing complexity is not about putting everything in one-line functions/modules.

社区一致认可的结论：你的模块必须含有一定的复杂性，不然就没啥意义了。

• 3）npm上那么多个模块，大多数都是无意义的吧？

从我开始讲Node.js全栈大约是3月份，那是npm上是25.6万个吧，截止到2017年3月是45万个，我想说的是那个包仓库都是有好有坏，按照80/20原则，数量是也是相当可观的。总比那些某些语言连包管理机制都不完善的要强太多了吧！

• 4）迫使npm调整了撤销策略，模块一旦发布，24小时之后就不让撤销了

If the version is less than 24 hours old, you can unpublish it. The package will be completely removed from the registry.

这世界是完美的？

没用过别逼逼我不同意，我在做新的项目之前仔细对比了 Node Web 框架与其他框架，发现 Node 的上述问题，才使用了别的。
我不认为我一定要用过之后再来逼逼。
你也是做过项目的，知道如果一个项目做毁了会有多大损失，我不会为了来逼逼而去做毁一个项目。
如果你技术一般，我建议你先别用 Node，因为会让你的技术更一般。
如果你技术很牛，我不需要建议你什么，你牛你先说。

没用过就是没用过，很多精髓的东西如果停留在表面，是不是太肤浅了？哪个框架是完美的？了解敏捷么？敏捷的基础认知是什么？

从上面那express和rails比，从对express是rest+mvc的描述，暴漏对node了解太浅。如果说想黑node，我再帮你补二刀，早年robbin范凯，一直在黑node的回调地狱，可是又如何呢？该有多人用还是有多少人用

有种你别装，装了就别瞎比比，既想当婊子，又想立牌坊吗？

至于项目能否做成功，我并不认为是技术的问题。更多的是你对技术的熟练程度，哪个熟悉就用哪个，你哪个自己不熟悉的，做毁了，然后来骂框架，骂语言？这也是神逻辑啊。

狼叔经常说：“少抱怨，多思考，未来更美好”，适用于所有人。

人员参差不齐要说人员参差不齐， Node 社区说第二，有哪个敢说第一？

PHP 好歹也是专注 Web 后台。Node 可笑的地方在于一群前端以为自己会后端就来写 Web 后台。我没有数据支持，但是我就是这么认为的。
Java 后台的新人也是第一天就会专注于后台方面的学习。
当然这并不能作为你不使用 Node 的原因，如果你是大神，你不会在乎这个社区有多少小白的。但是我前面也说了，我关注的大神都从 Node 社区走了啊。我为什么还要进 Node 社区……
阿里的苏千我在阿里的时候也有向他请教 Node 方面的知识，我从未否认他们的贡献，不过我并不会因此捧 Node。

PHP专注于Web 后台，我估计看了这话，鸟哥会哭的很伤心的。Node的人不是可笑，是有追求，慢慢写着写着就在成长。

Java 后台的新人也是第一天就会专注于后台方面的学习？呵呵，没学Java么？去看看core java吧，上来学后台，没见过。

关注的大神都从 Node 社区走了，这话更扯淡。哪个社区不是这样的？不同年龄，职位，人生阶段，关注点会不一样的。比如严清zensh就从node转了go，人家职位也不一样了。再有说话不要用“都”，我举个例子朴灵，https://cnodejs.org/user/JacksonTian，大家去看看他的最近参与的话题，10天前的。https://cnodejs.org/topic/5a20be0a110a338547d6e371#5a24c72b9178b0a14ac01e1b

最后，再说一件事儿，别老贴金，进了阿里不代表什么，马云说了，三年以上才算阿里人，才有阿里味。向玉伯，寒冬，苏千，朴灵，天猪等大大们致敬。

Hold 不住？

Node 呢，请问我该用什么数据库？用什么 ORM？用什么模板语言？用什么做后台任务？如何监控内存？如何分析日志？如何做分布式？如何做安全？有些人看说用 Node 做业务速度快，Node 的框架就做那么点低层次的封装，能不快吗？你把各种中间件加完试试？每个领域都要自己去找最佳实践，然后自己集成起来。

先不论对node和express等理解错误的问题。

先看狼叔之前的回复 https://www.zhihu.com/question/263855387/answer/273769595

一般，后端开发指的是 Web应用开发中和视图渲染无关的部分，但现在架构升级，Node承担了前后端分离重任之后，有了更多玩法。从带视图的传统 Web应用和 面向Api接口应用，到通过 RPC调用封装对数据库的操作，到提供前端 Api代理和网关，服务组装等，统称为后端开发，不再是以往只有和数据库打交道的部分才算后端，这样，就可以让前端工程师对开发过程可控，更好的进行调优和性能优化。

对Node.js来说，一直没有在后端取得其合理的占有率。原因很简单

• 1）利益分配，已有实现大多是Java或者其他语言，基本是没法撼动的，重写的成本是巨大的，另外，如果用Node写了，那么那些写Java的人怎么办？抢人饭碗，这是要拼命的。

• 2）Node相对年轻，大家对Node的理解不够，回调和异步流程控制略麻烦，很多架构师都不愿意花时间去学习。尽管在Web应用部分处理起来非常简单高效，但在遇到问题时并不容易排查定位，对开发者水平要求略高。

• 3）开发者技能单一，很多是从前端转过来的，对数据库，架构方面知识欠缺，对系统设计也知之不多，这是很危险的，有种麻杆打狼两头害怕的感觉。

• 4）Node在科普、培训、布道等方面做的并不好，国外使用的非常多，国内却很少人知道，不如某些语言做得好。

了不起是个不能随便说的词儿，对于 Node.js 来说，简化并发编程，用了不起来形容并不过分，在2009年横空出世时，确实是独一无二的。但在今天，已经8岁的 Node.js 有了更多、更为广泛的应用场景，它已经远远大于当初设计时的初衷了，我觉得用更了不起来形容已经不过分了！

你这个问题，很明显暴漏了自己的问题就是上面的原因之3。

开发者技能单一，很多是从前端转过来的，对数据库，架构方面知识欠缺，对系统设计也知之不多，这是很危险的，有种麻杆打狼两头害怕的感觉。

不懂架构，不懂数据库，还没有明白人带，那你用啥框架，语言能好呢？

• 1）复用已有基础设施，很明显比自己造轮子好。别动不动就java已死，xx已死的，冰冻三尺非一日之寒
• 2）微服务架构下，你需要多复杂？

不懂不可怕，别装懂。

UI 是 User Inferface，意思是 Node 社区做的工具的外观（UI）都很漂亮。

pm2 的 UI（命令行界面）我就很喜欢，Node 内容 Chrome 调试（界面）我也很喜欢，这是 UI，我不是说 GUI。程序员之间说 UI 难道不是既包括 GUI 又包括 CLI 吗？这只是对于术语的误解而已，不重要。

各位看官自己判断这句话吧。

所以 NodeJS 社区很明智，多多模仿其他成熟框架是对的。但我直接去看你模仿的框架就好。？

举例，我想学日语，结果发现日语里有汉语的影子，于是我去学了汉语？是这逻辑么？

水是原子组成的，干嘛喝水呢？去喝原子啊，反正有很多途径。。。

JS 全栈

我不知道这有什么意义？为了全栈而全栈？Java 二十年前也有一样的口号，然后呢？而且 JS 现在已经很奇怪了。

目前看js是最容易实现全栈的途径，没有之一。我很喜欢ror，但同时学2种还是略难。其他就更不要说了。Java是跨平台，能和JS一样么？你真的了解从applet到awt到swing到他们衰亡的历史么？不见得吧，说话还是要有理有据的。

全栈是信仰，是一种积极的人生态度。何谓为了全栈而全栈?我看到的更多的是大家积极的学习，努力的向提高成长。在技术变化如此快的今天，我们不是更该如此么？我尊重每一个有全栈信仰的人，我也祝福你们，未来是你们的。

关于语言他回复的2个点

• 我对Node新人的建议是玩一玩可以，不过要早点转 Go，因为 Node 并没有什么突出的优势。
• 我宁愿用 Java 都不会用 Node.js，除非工资特别高

一会扯go，一会扯java，难道对这门语言很熟悉的？还是纯粹为了挑起语言战争？还是为了培训机构站台？

大家姑妄言之，姑妄笑之就好，别认真，认真你就输了

朴大说过：“为什么非要尝试去说服傻逼”，可怜之人必有可恨之处，但不容许有人黑我大Node。

SpaceVim Layers: debug

原文： http://spacevim.org/layers/debug/

Description

This layer provide a debug workflow for SpaceVim. All of the function is based on vim-vebugger.

Install

To use this configuration layer, add call SpaceVim#layers#load('debug') to your custom configuration file.

Key bindings

Debug Transient State

key bindings is too long? use SPC d . to open the debug transient state:

免责声明

首发公众号【一名打字员】 本文记录了一名打字员的日常生活一天。仅仅代表本猿一名打字员的日常生活，不代表其它打字员。如有雷同，那么恭喜，你和本猿一样生活充满着尴尬。

2017-11-23

• 8:10-9:00 起床上班

昨晚睡前看了一集《极限挑战》，宿“剧”未醒，感觉整个人疲惫不堪难以醒来。没办法，为了生活，给了自己两巴掌（当然是脑补的）起床洗漱，公司9:00上班，换好衣服拿了一瓶红枣味酸奶和一小包三明治出门，到公司刚好9点。

• 9:00-9:30 瞎逛各大论坛 首先点开segmentfault，看看草稿箱里还有几篇存货，然后点开首页，看看热门问题和文章。自从写了几篇前端之后，感觉好像我的热门里面出现了许多以前都没有的推荐，难道segmentfault推荐算法也改进了（疑问句）。为了方便清楚的描述所逛的内容，本猿爬取了首页热门推荐的内容，并简单处理了一下，如下图所示：

当然为了博取小伙伴的眼球，我还换了一种风格。

是不是远远的看去像一位欲迎还拒的小姑凉（此处脑补n个字）

• 9:30-12:00 日常写BUG 这段时间处于机械编程式劳动，基本上是处于收到需求，解析需求，写BUG。或者是收到BUG，改BUG,写BUG。 中间程序编译的过渡阶段（这个阶段有的时候异常漫长，懂的猿请点个赞谢谢），通常会与各大企鹅群里的小伙伴进行撕逼，就某一个话题或者某一个知识点或者是不知道是啥东西的情况下进行激烈的讨论，然后午饭时间就到了。

• 12:00-13:00 午饭时间 有的时候点个外卖，有的时候去外面吃一个重庆小面什么的。千篇一律，没有任何波澜。

• 13:00-14:00 笔记和博客整理 刚吃完饭休息了一会儿，整理一下笔记内容，把一些知识点整理一下放在博客中。当然笔记里面的内容实在是杂乱无章，各种语言如C、C++、Python、Node、Vue、React、Java、Ruby、C#的小知识，大都是做项目时碰到了，然后随手粘贴复制到笔记本中，还有各种心情，奇怪（手动尴尬）。

• 14:00-17:00 继续写BUG 写了一会儿博客，发现新的BUG、新的需求又来了，又得不停的改BUG写BUG了，另外这段时间里又会产生无数次的撕逼。

• 17:00-18:00 忙里偷闲 手头的工作忙的差不多了，偷偷的逛逛知乎并把整理好的文章粘贴到公众号上发布。本来准备抓一下知乎自己日常浏览的动态，写完模拟登录（知乎需要登录，不然很多地方的内容无法抓取）然后抓了一下首页推送内容，做了一个分词权重的时候，发现结果有很多“少儿不宜”的关键字和图片（这里也许和关注的大V有关系），就不展示了。

• 18:00-19:30 日常加班 这段时间公司其它部门该下班的都下班了，就剩技术部在坚守岗位，没办法，还有太多的bug和改不完的需求在等着我们，遇到上线，还要再晚一点，所以说打字员是门苦力活没毛病儿。

• 19:30-20:30 晚饭回家 解决一下晚饭，然后背上行囊，扛着枪举着炮一路走去回家的方向。这个时候的上海是让我觉得最舒服的，一个人走着，也没人认识你，想想今天又过了一天，感觉啥也没干，想起没修完的BUG…啥，当我没想起来… 回到家刚好8:30左右。

• 20:30-21:00 洗漱 写了一天BUG了，回到家只想先好好的洗个澡，沐浴更衣一下，然后打把游戏或者看个电视什么的。

• 21:00-23:30 游戏睡觉 打开某网络播放器，刷了一圈没有看到好看的剧。就叫上室友一起手游，最近一个网易手游在公测，具体和“吃鸡”差不多，和室友玩的也是昏天黑地，比如说正在与三人徒手决斗的时候，室友突然驾驶一辆破面包车来单独撞死了我。又或者是说好的掩护我，自己一个人偷偷跑掉。就是这样的室友我依然没有嫌弃他，最后临睡前带着他吃了一把“鸡”。 关上手机，刚好23：30，躺下想了想自己还没赚到的一百万和还没有升职加薪，带着一股浓浓的忧愁翻了个身睡觉。

自我评价

这就是本猿一个普普通通的打字员的日常，平常除了写写BUG，追追番和打游戏之外，几乎找不到其它的乐趣。每天晚上都骂这个世界让自己活的这么窝囊，要不甘平凡，第二天早上却继续拖着疲惫不堪的身体又开始继续碌碌无为的一天。总想着自己可以改变世界，但是却混不知自己正在一点一点被时间改变。

像我这样优秀的人，本该灿烂过一生，怎么二十多年来还在人海里浮沉。 像我这么碌碌无为的人，你还见过多少人。

坐标：北京望京 薪资：20-35（14 到16个月） 要求：三年以上前端经验，js功底较好，熟悉前端主流框架 如vue react等 公司现在主要的前端技术栈：react+redux+webpack，所以熟悉react+redux优先，本人前端程序员，有意者发送简历 到luckylin87@sina.com 或者微信号/qq 782307193

下载文件时不是直接下载文件，所以不能直接使用express的sendfile方法,自己生成文件写到response里面，但是当文件很大的（如超过5G），生成速度过快导致内存泄漏，一般怎么解决比较好点，目前有如下两种思路： 1.生成一部分然后睡眠，从而控制生成速度 2.直接生成到服务器然后下载 网大神提供下思路

期望

通过node执行ssh-keygen无需交互式输入密钥，因为要做自动化，密码是事先知道的，无需再次通过命令行输入。 不要通过参数-N进行输入密码，因为不是每个命令都会有-N这个参数，我想知道针对ssh-keygen和ssh-copy-id这样的命令如何进行交互式输入。

问题

通过childprocess.spawn 执行ssh-keygen和ssh-copy-id命令时，每次等到输入密码时，stdout就监听不到数据了。 ssh-keygen命令好像在执行密码的时候，不是在子进程进行输出的。

测试代码

const {
	spawn
} = require('child_process');
const child = spawn('ssh-keygen');

child.stdout.on('data', (data) => {
	let content = data.toString();
	console.log('child.stdout: \r\n'+ data.toString())
	console.log('wirte begin:\r\n')
	if (content.indexOf('Enter file') >= 0) {
		child.stdin.write("id_rsd\r\n");
	} else {
		child.stdin.write("empty\r\n");
	}
	console.log('write end \r\n');
});

打印内容

root@iZ1193ih9wgZ:~/test/nssh# node shell.js
child.stdout:
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
wirte begin:

Enter passphrase (empty for no passphrase): write end

测试测试

分享一些学习资源

主要是node + 前端 + 常用技术 喜欢要star，有资源要提request哈 废话不多说，地址在此：https://github.com/threerocks/studyFiles

ps: 不经典，不分享

介绍

一些高质量电子书资源分享

不可否认书籍，尤其高质量书籍对于程序员的重要性，不管是学而时习之，还是温故而知新。 所有书籍类资源都逃不过版权问题，这个层面上还是希望有能力的人支持正版。 如果不喜欢此共享方式，请点击关闭窗口。 如果你喜欢请点击star，如果恰好你手上也有一些好的资源方便大家分享，欢迎上传（pull request）

上传

欢迎大家上传手中资源方便大家共享，所有pull request我本人都会通过，但是会严选一下，这一点还请大家见谅，毕竟书籍存在质量、清晰度或者重复等等问题。

历史

项目本来作为个人资源，目的是个人方便不同地点共享阅读，并把一些经典书籍存储下来。 意外收获很多朋友的喜欢，并且有很多小伙伴提了pull request

    2016/11/24  100 
    2017/01/12  200
    2017/03/19  300
    2017/08/20  400
    2017/11/11  500   合并三位小伙伴上传资源
    2017/12/12  600+  增加go语言分类

引用

你可以随意引用此项目分享给更多的人

如果你喜欢可以标注 转载自：https://github.com/threerocks方便的话可以提示star

介绍

项目是学完慕课网课程Vue.js高级实战—开发移动端音乐App后，独立开发，也是第一个vue程序。

项目与慕课网课程相比有很大区别，

• 样式代码改为使用了纯css编写
• 后端api改为使用网易云音乐Api + 自己编写的一些接口
• 由于数据以及类型等等不同，几乎修改了所有相关方法
• 搜索页面自己重新设计
• 图标icon全部来自阿里巴巴矢量图标库
• 播放器/搜索部分做了移动端适配，主要是blur属性引起卡顿，ios端radio无法自动播放等等。
• 因为移动端限制自动播放，设置第一次进入播放为暂停状态

预览地址

http://music.threerocks.cn/

安装与运行

git clone https://github.com/threerocks/rock-music

cd rock-music

npm install

npm run dev 

npm run build 项目打包 

感兴趣的童鞋可以来个star

职位描述:

1. 负责蘑菇街电商业务的产品支撑，以及业务相关的组件、平台开发。
2. 探索实践新技术，参与技术体系建设（流程、规范、工具等），提升前端效率和质量，帮助业务快速成长。

职位要求:

1. 熟练掌握Web前端知识（HTML/CSS/JavaScript），有Vue.js、React方面的实践经验。
2. 熟练掌握PC/移动端开发，熟悉相关性能优化措施；有混合开发实践（React Native/Weex等）优先考虑。
3. 了解服务端知识（PHP/Java/Python等），有一定的实践经验。
4. 有Node.js实践经验优先考虑。
5. 有2年以上互联网产品前端开发经历。
6. 有良好的自我管理能力及开放的心态，善于沟通协作，有执行力和推动力；有持续的学习热情、成长意愿。

简历投递邮箱：mozheng@meili-inc.com

使用protobuf的时候必须得先把.proto文件定义好，但是很多时候需要解析的数据内容是不确定的，能动态解析么？ 解析库用的是 protobuf.js或者有更适合的库？

Video++，创建视频消费场景|视频电商/AI/广告 月独立用户2.8亿 总人数120人左右，已获得新一轮3.5亿融资，单月收入已破2000万。 我们为芒果TV，战旗，全民等点播直播平台提供完整视频内电商系统，实现边看边买。

公司地址：黄浦区中山南路 联系方式：hr@videopls.com 官网：www.videopls.com

招募岗位：前端开发工程师 薪酬：20k~25k 奖金：1~4个月 岗位职责：

• 开发视频/直播互动/视频电商JSSDK
• 持续优化前端体验和页面响应速度，并保证浏览器兼容性和执行效率
• 进行系统优化，设计并完善前端基础服务架构
• 与后台技术、产品经理保持良好沟通，快速理解消化需求，并落实为具体的开发工作 要求：
• 本科毕业
• 3年以上正式工作经验
• 基础知识扎实，熟练掌握JS及React
• 沟通能力优秀，性格开朗 彩蛋：
• 足额五险一金
• 免费加班餐
• 每年旅行
• 配Mac

要做爬虫的HTTP代理池, 发现google上搜的免费代理, 基本上都根本用不了, 就是HTTP请求都没法代理. 付费的HTTP代理里面: 找了个快代理, 用了他们的私密代理, 试了十几个, HTTP请求能够正常代理的, 但貌似代理的ip都在淘宝的爬虫黑名单. 找了淘宝上的, 买了一个ip试了一下, 完全ok, 但是要每个ip 20元/月, 多买些IP太贵了. 请做过爬虫代理池的大牛分享一下资源哈.