From 114c0d5677b4208c0b1a32cacd3781a6f54bde90 Mon Sep 17 00:00:00 2001
From: coderLMN
+
+ int myfunc(int q, int p) { return p%q; }
+
+
+
+ ...
+
+
+
+ myfunc(6291, 8)[Array];
+
+
+ + 遗憾的是,这一招只能在本地C类里用,Java 还不行。 + +
+ + 如果我们对自己的编程能力有充分信心,那么测试就没有必要了。如果我们逻辑地看待这个问题,随便一个傻瓜都能认识到测试根本都不是为了解决技术问题,相反,它是一种感性的信心问题。针对这种缺乏信心的问题,更有效的解决办法就是完全取消测试,送我们的程序员去参加自信心培训课程。毕竟说起来,如果我们选择做测试,那么我们就要测试每个程序的变更,但其实我们只需要送程序员去一次建立自信的培训课就行了。很显然这么做的成本收益是相当可观的。 + + + +
+ 计算机语言正在逐步进化,变得更加傻瓜化。使用最新的语言是不人性的。尽可能坚持使用你会用的最老的语言,先考虑用穿孔纸带,不行就用汇编,再不行用FORTRAN 或者 COBOL,再不行就用C 还有 BASIC,实在不行再用 C++。 + +
+
+
+
+
+
+
+ +
+ +++ + 如果你给某人一段程序,你会让他困惑一天;如果你教他们如何编程,你会让他困惑一辈子。 + -- Anonymous
+
+
“伙计们,让我们坦诚一点。 Sturgeon定律说90%的东西都是垃圾,他太理想化了。代码中垃圾的比例远远不止90%。” – Al viro(Linux内核的核心贡献者之一)
+ +“有两种构建软件设计的方式:一种是把它做得特别简单,明显看不出来有什么缺陷;另一种是把它做得特别复杂,看不出来有什么明显的缺陷。” – C.A.R. Hoare, 1980年 图灵奖获奖感言
+ +“生产效率最高的一种方法是去掉1000行代码。” – Ken Thompson (Unix 和 Go 语言 作者)
+ +“在我们行业里有个奇怪的现象:我们不但不从错误中学习,也不从成功中学习。” – Keith Braithwaite
+ +这项统计工作还在进行中,很多有害技术还没能列入:
+ +| 有害的技术 | 害处较少一些的替代技术 |
|---|---|
| SGML, XML, YAML. | JSON, CSV, ndb(6), plain(UTF-8) text. |
| NFS, SMB, AFS, WebDAV. | 9p. |
| C++, Java, Vala, D, Python, Ruby. | C, Go, Limbo. |
| pthreads (PoSix threads). | CSP-style concurrency: Go, libthread, libtask, Limbo, Erlang, ... |
| Perl, Ruby. | rc, awk. |
| PCRE | Structural Regular Expressions or plain classic/extended regexps (as used in awk, sed, grep, etc.). |
| Bash, tcsh, zsh. | rc, OpenBSD's pdksh, ash/dash. |
| GNU Coreutils. | Plan 9 from User Space. |
| GNU Screen. | tmux. |
| GNU info. | Man pages. |
| GCC. | 8c, tcc. |
| glibc. | ucLibc, DietLibc. |
| GNU autoconf/automake, CMake, imake, scons, waf. | mk, or plain old portable makefiles. |
| Glib. | libc (see above), p9p's C libraries. |
| GTK, Qt, VxWindows. | Tk, textual interfaces. |
| Vim, Emacs, nano, Eclipse, ... | Acme, Sam, ed. |
| UTF-16, UTF-32, Latin-1, other encodings. | UTF-8. |
| iSCSI, FCoE. | AoE (ATA over Ethernet). |
| PAM (Pluggable Authentication Modules). | Factotum. |
| Jabber and XMPP. | IRC (for IM), STOMP (for general distributed messaging). |
| IMAP. | SMAP(Simple Mail Access Protocol). |
| SQL databases. | Tutorial D, pq, BigTable, plain old hierarchical filesystems. |
| Subversion, aka svn. | Git, Mercurial (aka hg); hell, even CVS or plain old tarballs would be better than svn. |
| FreeBSD, NetBSD, Solaris. | OpenBSD. |
| Apache, lighttpd. | thttpd, OpenBSD's fork of apache 1.3, nginx, or best of all: don't use HTTP. |
| SVG | PS(PostScript) |
| PS(PostScript), DjVu. | |
| EPUB | DjVu. |
| ALSA | OSS4 |
| GPL, LGPL, Apache Software License, MPL, CC. | ISC, MIT/X, BSD, CC0, public domain. |
| head | sed 11q |
View the Project on GitHub coderLMN/frontEndCourse
- +| 前后端交互演示 | +可动态定义多层级选择框演示 | +动态加载html片段演示 | +
| HTML5 视频加遮罩演示 | +SVG刻章办证演示 | +原生代码实现jQuery的Tab效果演示 | +
| 【译文】如何编写无法维护的代码 | +【译文】isobar公司前端代码规范及最佳实践 | +【译文】前端开发指南 | +
+ BitWorking+如题。 +
+ +翻译版: 日语
+ ++JS框架看上去就像死亡和纳税,必然发生,无法避免。如果我能变成一只苍蝇趴在墙上,我就能确定每次启动一个新项目的时候,他们讨论的第一个问题肯定是:我们要用哪个JS框架?这种场景反映了当今JS框架的角色在行业里是多么根深蒂固不可动摇。但其实这种形势并非是必需的,而且实际上,这种做法需要制止。 +
+ ++让我们先回顾一下我们是怎么一路走来的。 +
+ ++ +Angular 和 Backbone 还有 Ember,我滴个天哪。
+长期以来,用最简洁的 HTML+CSS+JS 方式表述的web 平台,从技术栈的角度看是一场灾难。谁能忘记IE的盒子模型或者layer标签?我知道,那些例子会引出web开发中一些令你不堪回首的往事。 + +
+ ++很长时间里,浏览器之间存在大量的不一致,而我们作为一个行业,只能靠编写框架来糊裱一番。问题在于当时在不同浏览器之间对于一些基本问题都存在争议,例如事件如何传播或支持哪些标签,导致每个框架不仅糊裱了缺陷,而且还设计了他们对于浏览器功能的模型。实际上他们自己的模型都是多个,因为你要发明事件传播的模型,还有与DOM交互的模型,等等。这里边有很多新发明。随之出现了一些框架,然后聚沙成塔集腋成裘,就产生了大量诸如jQuery 、Dojo、MochiKit 、ExtJS 、AngularJS 、Backbone 、Ember 和React 等等玩意儿。在过去的十年里,我们不停地折腾出了成堆的框架。 +
+ ++但是过去的十年里还发生了其他一些事:浏览器越来越好了。它们改善了对标准的支持,现在出现了自动更新的常青浏览器,它们的每个版本都比旧版本更适应和符合标准。这些新标准比如: +
+ ++我认为现在是时候重新思考JS框架的模型了。做Web 开发没必要再发明其他的方法,只要使用 HTML+CSS+JS 就行了。 +
+ ++那么,为啥我们还在编写 JS 框架呢?我觉得这很大程度上是因为惯性,它成了一个习惯了。不过,有人要说,这种习惯有那么糟糕么?框架看起来也并不是有害的,对不?嗯,让我们先从我说的框架定义开始分析。实际上这些代码是有个增强的梯度,从代码小片段开始,例如Gist,逐渐扩大到越来越大的代码集,形成了库,最终产生了框架: +
+ ++ +gist -> library -> framework
+量变引起质变,框架已经不再仅仅是大型的库,它们有自己的一套与事件、DOM等交互的模型。那么,为啥要避免用框架呢? +
+ ++抽象 框架的一个问题往往也是它们的卖点,那就是它们把平台抽象了,这样你就能集中精力写你自己的软件。问题是,现在你需要学习两套开发系统,HTML+CSS+JS 和框架。当然了,假如某个框架能做到把web平台完全抽象化,那你就永远不需要涉足到框架之外,但是你猜怎么着? 抽象也会泄露。所以你需要了解 HTML+CSS+JS ,因为某些情况下你的程序不会按你所期望的方式工作,你需要深入框架内部的各个层直到 HTML+CSS+JS,才能找到出错的原因。 +
+ +++ ++ 绘制冰山图 +
+
+一套框架就像一座冰山,浮在水面上的10%看起来并不危险,最终让你船毁人亡的是隐藏在下面的那90%。实际上更合适的一个比喻是,学习一套框架就像对一座冰山绘图,也就是说,为了使用框架你必须学会框架里所有的内容,花精力去把所有的内容对应到传统的 HTML+CSS+JS,从长期来看这个过程毫无意义,因为冰山最终都会融化。 +
+ ++小组件 框架的另一个卖点是你可以获得一个小组件的库。可实际上,你并不是非要运用一套框架才能得到它们,它们应该是和框架无关的独立功能。这方面的一个好例子是 CodeMirror,这是一个用Javascript 编写的语法标记代码编辑器。你可以在任何地方使用它,无需任何框架。 +
+ ++给某个框架编写小组件也是吃力不讨好的事。还记得你在MochiKit 框架下编写的那些小组件吗?现在你转移到 Ember或者 Angular后,它们还好用不? +
+ ++数据绑定 老实说,我从来用不着它。不过如果你需要的话,它也应该以库的形式出现,而不是框架。 +
+ ++框架带来的更长期的问题是它们最后变成一个一个地窖,把整个版图分割成片,给A框架编写的小组件无法在B框架下使用。这就是事倍功半。 +
+ ++那么问题就来了:后框架时代的世界是什么样的呢? +
+ +++ ++HTML+CSS+JS 就是我的框架。 +
+
+基本思路就是不再需要框架,使用 HTML+CSS+JS 中已经包含的能力去编写你的小组件就行了。把一块块巨石打散成独立的、可以任意组合的组件。按这个原则最终划分出的各块组件都成为Web 组件中的一部分。 +
+ ++HTML 引入, HTML 模板, 定制元素, 以及 Shadow DOM 都是有助于我们砍断框架束缚的有力技术,使我们能够产生可重用的元素和功能。要想更详细地了解这些技术的情况,请参阅以下文章和库:
+ ++那么,是不是说我们都可以创建 <x-flipbox>然后就万事大吉了呢? +
+ ++不,并不是这样。运用 Web组件 需要做的第一件事是填补那些功能,例如 X-Tag 和 Polymer。不过随着浏览器逐渐填补对于这些规范的实现,这些工作的必要性会逐渐减少。 +
+ ++在这里需要强调的一点是这些补丁并不是指那些自创一套 Web 开发模型的框架,它们只需要应用HTML 5模型就行了。但是那并不是真正唯一的需求,在Web平台上仍然有微小的缺口,每个浏览器都在一些细节上偏离当前的标准,这才是我们需要填补的地方。MDN 看起来已经有很多所需的代码了,因为其中的文档经常包含了短小的针对每个功能的补丁。
+ +
+那么,一个巨大的 HTML 5 补丁库也许不错,但是更好的办法是我称之为 html-5-polyfill-o-matic
的一套工具,它让我能通过标准HTML+JS 来编写Web组件,然后分析我的代码 -- 通过静态分析或者运行时的 Object.observe ,使它可以精准地从完整HTML 5补丁中产生我的项目所需的一套子集。
+
+如果我开始尝试混合和匹配来自多个来源的Web组件 -- 例如来自 X-Tag 的 <x-foo> 和来自Polymer 的 <core-bar> ,这种功能会变得更加重要。是不是这就意味着我必须引入它们两者的补丁库呢? (看起来答案是否定的。) 我又要如何获取这些定制元素呢? X-Tag 和 Brick 两者都有定制绑定生成器: +
+ + + ++如果我开始生成定制元素,我是否需要生成我自己的定制绑定器呢?我不认为那是个可扩展的思路,我相信我们需要能更好处理这类问题的惯例和工具。这实际上可能意味着改变我们进行开源项目的方式,一个小工具并不是一个项目,所有我们处理这类问题的方法需要改变。当然了,还是要把代码放到Git里,但是你是否需要一个GitHub项目的整体开销呢?可能更好的办法是更轻量级、接近Gist的方式。我如何才能把vulcanize 里所有这些代码压缩成合适的形式用到我的项目里去?类似于 Asset Graph 的例子也许是个合适的起点。 +
+ ++那么,我们现在需要的是什么? +
+ ++这就是我们在未来构建Web应用时所需要的一切。在那时,我们不再需要学习最新框架的最新模型,而是直接针对Web 平台工作,引入定制元素和库来满足特定需求,把时间花在编写应用上,而不是去绘制冰山图。 +
+ +Q: 你为啥憎恨框架作者呢?
+A: 我不憎恨他们。我有些最好的朋友就是框架作者。我承认从搞笑文章 《你已经毁了Javascript》 中得到了一点灵感,不过我要再次说明,我无意嘲笑框架作者。 +
+ +Q: 你可以用HTML 5实现 ____ 功能,但为了这么做你需要一套框架
+A: 首先,那不是一个问题。其次,感谢指出这一点。现在让我们一起努力增强HTML 5的能力,让____ 功能可以不用框架就能实现。
+ +Q: 但是 ___ 并不是框架,它是一个库!
+A: 是的,正如我所说,它是从gist 渐进到框架的,可能你的划分方式和我稍有区别。没关系,这篇文章的重点不是对特定软件的分类,而是远离框架。 +
+ +Q: 我这么干活已经很多年了,用了 ___ 和 ___ 还有 ___。
+A: 这也不是一个问题。不过无论如何,这对你是有好处的,你应该处在了帮助其他人的有利位置。 +
+ +Q: 这么说每个人都需要重写下拉菜单、标签页、滑动条,并自己实现切换功能?
+A: 绝对不是这样,关键是应该用一种不限定在某个框架的方式来创建这些元素。 +
+ +Q: 伙计,所有这些 HTML 引入会把我网站的性能搞死的。
+A: 是的,如果你在本地实现所有这些功能的话,这也是我前面 +提到用来编译和压缩HTML+CSS+JS的工具的必要性 的原因。
+ +Q: 那么我就不要用 任何 库喽?
+A: 不,那不是我表达的意思。我在区分库和框架这方面非常谨慎。库提供的是可以配合其他库使用的独立功能块。库很好啊,我希望看到大家一致赞同远离的是 框架。 +
+ +Q: 可是我喜欢数据绑定!
+A: 很多人都喜欢,我只是表达个人喜好罢了。我也没有说 你 不应该使用数据绑定,我只是说你不需要为了实现数据绑定而运用一整个框架而已,有一些独立的库就可以做到了。 +
+ + + +2014-05-09
+如题。
- +翻译版: 日语
From 103a327575fbacaf89e48db87664b8d36ffae844 Mon Sep 17 00:00:00 2001
From: coderLMN 别再用JS框架了
翻译版: 日语
From 88b0648ce9acfe4ff1e4098c98274405e115722b Mon Sep 17 00:00:00 2001
From: coderLMN Your video
+ Please share your video camera and microphone to start group chat.
+
+
+ Other users must input the same room name to join this chat room.
You can set a long and complicated 'room' name (something like 'axdi394029kdkekdkgkbs4532'), which is only known to the people you invited, to setup a private chat room.
+
+ Chat room name:
+
+
+
+
+ Friends
+
+