IT圈子,ITBBB.COM

国外前端高质量技术文章网站汇总

2019/10 20 19:10

以下是整理的的一些经典的国外技术网站,能收获很多前沿的技术信息,可以经常浏览一下。

(有些网站可能需要科学上网才能访问)

1.https://speckyboy.com/

 

2.http://www.echojs.com

一个专注前端高质量技术文章汇总的网站

 

3.https://news.ycombinator.com/

传说中的Hacker News,来这里,总会有收获。

 

4.https://frontendfront.com/

看域名就知道是干什么的了,想看前端最前沿的文章来这准没错

 

5.https://tutsplus.com/

用英文说就是:far beyond my description

 

6.http://www.lesslinks.com/

官网首页文字介绍:World’s best curated list of quality resources for designers, learners and techies

 

7.https://uptodate.frontendrescue.org/

每天有数以百计的博客和文章,但你没有办法阅读所有的文章。我们认为你应该有一种方法来保持阅读最新的文章,所以我们创造了这个食谱。

 

8.http://stackoverflow.com/

问答类网站

 

9.https://www.quora.com/

问答类网站

 

10.http://www.codewars.com/

是时候展现真正的code了

 

11.https://www.html5rocks.com/en/ (英文)    https://www.html5rocks.com/zh/  (中文)

 

12.http://www.javascriptkit.com/

 

13.https://css-tricks.com/

 

14.http://tympanus.net/codrops/

 

15.http://red-team-design.com/

 

16.http://tutorialzine.com/

 

17.http://csswizardry.com/

 

18.https://www.smashingmagazine.com/

 

19.https://www.script-tutorials.com/

 

20.https://scotch.io/

 

21.https://wefunction.com/

 

22.http://webdesignerwall.com/

 

23.http://blog.teamtreehouse.com/

 

24.http://html5bookmarks.com/

 

25.https://dzone.com/

 

26.http://www.cssauthor.com/

 

27.https://www.sitepoint.com/

 

28.http://callmenick.com/

 

29.http://sixrevisions.com/

 

30.http://www.css-jquery-design.com/

 

31.http://www.developerdrive.com/

 

 

原文 https://www.cnblogs.com/handoing/p/6082759.html

用npm package-lock或shrinkwrap管理项目依赖

2018/05 22 09:05

管理node依赖是前端开发过程中会遇到的问题。

在Node.js项目开发的时候,我们也经常需要安装和升级对应的依赖。虽然 npm 以及语意化的版本号 (semantic versioning, semver) 让开发过程中依赖的获取和升级变得非常容易, 但不严格的版本号限制,也带来了版本号的不确定性。主要的问题可能有三个:

npm 建议使用 semver 的应用程序版本,但这也完全依赖第三方包遵守这一规则。如果你依赖于的包不遵循 semver ,或者依赖的包的新版本有重大更改(而你使用了 ^ 的宽泛版本安装),这潜在可能是会导致问题的。

另一个问题的出现是由于 npm 安装依赖的机制。npm 的安装包是有层次结构的,手动控制要安装的软件包的版本号可以实现,但是你只能在 package.json 使用精确的版本号控制你的直接依赖包,但那些多层以上的依赖就没办法控制了;一个第三方包不严谨的版本依赖生命可能破坏你的依赖管理。

在开发阶段执行得到的版本,和后续部署时得到的可能是不一致的,更不可控的是,你依赖的第三方包也有这样的情况会导致潜在的上线风险。

如果要控制上线的风险,我们就必需要解决这个问题,这时候,推荐使用 npm shrinkwrap 这个命令来解决问题。

这个命令在node 5版本之后改成了npm install的时候自动生成package-lock.json,其功能和npm-shrinkwrap.json是一致的,只不过shrinkwrap是手动生成的,在此请各位注意

关于package-lock.json/npm-shrinkwrap.json

npm install / shrinkwrap 可以按照当前项目 node_modules 目录内的安装包情况生成稳定的版本号描述。

比方说,有一个包 A

     {       
     "name": "A",       
     "version": "0.1.0",       
     "dependencies": {         
         "B": "<0.1.0"
       }
     }

还有一个包 B

     {       
     "name": "B",       
     "version": "0.0.1",       
     "dependencies": {         
         "C": "<0.1.0"
       }
     }

以及包 C

     {       
     "name": "C",       
     "version": "0.0.1"
     }

你的项目只依赖于 A,于是 npm install 会得到这样的目录结构

   A@0.1.0
     `-- B@0.0.1
         `-- C@0.0.1

这时候,B@0.0.2 发布了,这时候在一个新的环境下执行 npm install 将得到

 A@0.1.0
     `-- B@0.0.2
         `-- C@0.0.1

这时候两次安装得到的版本号就不一致了。而通过 install/shrinkwrap 命令,我们可以保证在所有环境下安装得到稳定的结果。

在项目引入新包的时候,或者 A 的开发者执行一下 npm install / shrinkwrap ,可以在项目根目录得到一个 package-lock.json/npm-shrinkwrap.json 文件。

这个文件内容如下

{  
     "name": "A",  
     "version": "0.1.0",  
     "dependencies": {    
         "B": {      
         "version": "0.0.1",      
         "dependencies": {        
         "C": {          
             "version": "0.0.1"
            }
      }
    }
  }
}

shrinkwrap 命令根据目前安装在node_modules的文件情况锁定依赖版本。在项目中执行 npm install 的时候,npm 会检查在根目录下有没有 package-lock.json/npm-shrinkwrap.json 文件,如果文件存在的话,npm 会使用它(而不是 package.json)来确定安装的各个包的版本号信息。

这样一来,在安装时候确定的所有版本信息会稳定的固化在 package-lock.json/npm-shrinkwrap.json 里。无论是A,B 和 C中的版本如何变化,或者它们的 package.json 文件如何修改,你始终能保证,在你项目中执行 npm install 的到的版本号时稳定的。

在开发中使用 shrinkwrap

在开发过程中,引入一个新包的流程如下

npm install PACKAGE_NAME@VERSION --save 获取特定版本的包

测试功能

测试功能正常后,执行 npm install/shrinkwrap 把依赖写入 package-lock.json/npm-shrinkwrap.json 文件

在代码仓库中提交 package-lock.json/npm-shrinkwrap.json , package.json 描述

升级一个包的流程应该是这样

npm outdated 获取项目所有依赖的更新信息

npm install PACKAGE_NAME@VERSION --save 获取特定版本的包

测试功能

测试功能正常后,执行 npm install/shrinkwrap 把依赖写入 package-lock.json/npm-shrinkwrap.json  文件

在代码仓库中提交 package-lock.json/npm-shrinkwrap.json , package.json 描述

删除一个包的流程如下

npm uninstall PACKAGE_NAME --save 删除这个包

测试功能

测试功能正常后,执行 npm install/shrinkwrap 把更新的依赖写入 package-lock.json/npm-shrinkwrap.json  文件

在代码仓库中提交 package-lock.json/npm-shrinkwrap.json  , package.json 描述

比一般的安装多了一步手工生成 package-lock.json/npm-shrinkwrap.json  文件。在实际工作中,有时候我们会忘记这一步,导致上线时候没有获取到依赖包的特定版本。

小结

通过引入 package-lock.json/npm-shrinkwrap.json  文件,我们可以较好的管理项目的依赖关系,让上线变得更轻松。需要注意的是,尽管相关工具可以帮助你减化工作流程、可靠的分发依赖描述,但工具不能取代功能测试;每次升级依赖版本之后,我们仍然应该进行相关测试来确保项目能可靠的运行在该环境中。

为什么我们还在使用那些陈旧的技术

2017/12 29 16:12

好久不见,技术又革新了吗?我今天来的目的就是解释一下如下几个问题:

1.为什么很多企业单位还在使用Win7,甚至是WinXP,政府机构尤为突出?

2.为什么很多公司前端程序员还在使用jQuery?

3.为什么我们的父母坚决抵制把钱存在互联网金融?

future-2

最近产生了改了一批旧代码,有一些感触,为什么我们还在使用那些陈旧的技术?

最近帮朋友解决一个小问题,看了一下某国有企业的ERP系统代码,我的天哪,是.net写的,而且是WebForm写的,这如果在10年前,绝对属于新技术,从asp时代走到HTML与Server分层书写,能用这种技术写出这么庞大的系统,今天一定是年近四旬的大神了……哈哈哈。

还是最近,梳理了一个用requirejs写的项目,项目写的很复杂,能看出来设计是用心了的,放在三五年前,requirejs的模块化开发的思想还算是先进技术,可是当时写的人如果不在了,后人的维护成本将急剧增加。

我不禁反思,是技术进步太快还是我们转向太慢?这些年究竟发生了什么?经过长时间的琢磨与梦研,我得出了一些不确定正确的观点:

1.利益方与思维习惯的阻力令人发指,让旧技术得以保留。

政府为啥用旧系统?企事业单位为啥用古老的管理系统?原因主要有二。

其一,当时花巨资采购的时候级级拨款,层层审批,绑定了一批利益群体,没有人愿意站出来花力气革新,因为你行将搬起石头砸了自己的脚,试想为什么这批系统刚用了2年就又换新(如果这个系统是2年前开始使用的,那么它一定是3年前开始编写的)?于是再拖一年再升级吧,不然财务支出上无法向上级汇报,一年后经过各种复杂审批,终于决定升级系统,于是开始了漫长的招标过程,这其中又有太多的商业利益,折腾一年半载终于有了候选乙方,开始做需求调研吧,开会、出差、各种讨论会议,快的话又经过了三五个月才能进入编码阶段,反而编码倒是蛮快,经常是催催催(程序员加班的根源),可能三四个月就完成了,这时候你会发现离上一个系统最少三四年时间已经过去了。

其二,我都使用了三四年的Win7和ERP系统,如果换了又要产生新的学习成本,可能触及很多老员工老领导的习惯问题,所以在这方面革新也会受到不小的阻力,很可能新系统在上线后很长一段时间使用不起来,大家还是习惯在老系统上办公,直到有一天下了死命令,必须使用新系统进行办公,否则……,于是大家硬着头皮开始用。

2.商业价值是陈旧的技术的保护伞

对于程序员还在使用陈旧技术编程的问题,首先我要恭喜你,因为你还在维护陈旧的代码,起码说明了一点,在商业上这批代码还有价值,还有金主替他买单,不然没人会逼着你改这些目不忍视的代码。因为当年这系统就是用jQuery写的,你要维护他,就必须用jQuery,重写一遍的代价太大了,而且存在了几代程序员的更替,很多坑都不得而知,经常会出现改了一行代码,莫名的程序就运行不起来了……于是商业的保护伞也触发了人类惰性的根源,既然老技术也不错,很多地方都在用,就一直沿用吧……

3.固守的思维方式是时间给的烙印

互联网金融近几年大行其道,当你劝说你的父母把积蓄放到上边能获得比银行更高的收益的时候,他们表现的往往是坚决抵制,誓死不从。最常见的理由是 —— 不安全!对于70年之前的人,他们在银行体系下受益并生存了长达几十年之久,你让他们放弃简直是颠覆性的,当然不乏有思想开放的一些人,他们最先拥抱变化,甚至创造变化,想想互联网界如今顶端的大佬,马云、马化腾、柳传志无疑都是那个年代思潮的先驱。可视99%的人都是凡人,我们不能责怪他们冥顽不灵,因为你没有生活在他们当时的年代,很多事情你无法理解。

殊途同归,这三个问题,最主要的原因我姑且都归咎于是思想的滞后导致行动的滞后,而思想又是最难以改变的东西,都说“江山易改本性难移”就是这个道理了。时代的车辙滚滚向前,走出安逸区,不停的刷新自己的认知,去学习,去积累,去升华自己,才能成为那1%的阶级跃迁者。

 

欢迎关注公众号,我们会不定期分享前沿技术、学习资料,在前端的道路上一起成长

qrcode_public

 

 



无觅相关文章插件,快速提升流量