Jekyll 之类不是所见即所得系统写文章太累了，容易分心。以前我也自己写过一个非常灵活的静态网站生成工具 PlainSite，但现在还是放弃了，等以后重写一个 GUI 静态网站生成工具。

JexCheng Blog: https://jex/

现在的比特币就是纯粹浪费电能

直到今天还有人想抄底比特币呢，这些人股票期货外汇一样不懂，对比特币却说得头头是道，估计他们的经济学是从《货币战争》学来的

早该作出改变了，多向 Python import 学学

注意是反向域名解析： https://github.com/JexCheng/plain_site/blob/master/lib/plain_site/socket_patch.rb https://stackoverflow.com/questions/1156759/webrick-is-very-slow-to-respond-how-to-speed-it-up

Cloudflare CDN 速度还能接受

#5 楼 @davidwei 看来我想当然了，不过这也只能怪 Ruby 自己了，Array#& 是 C 实现的，而 Set模块是用 Ruby 实现的…一个比 Array 更需要高效率的场景反而用 Ruby 写

不过你的测试代码不太好，集合太小，并且不是随机数据，Array#include?理论是比Set#include?慢的，但看 Ruby 源码，Array#& 方法已经将数组转换成 hash 再求并集的，所以求交集并集能和 Set（数据结构意义上的 Set，Ruby 中的 Set 模块太令人失望了）一样高效。

看下面测试：

require 'benchmark'
require 'set'
GC.disable 

ary = (1..1000).to_a.shuffle
subary = (1..100).to_a.shuffle
set = Set.new(ary)
subset = Set.new(subary)
iterations = 2000

Benchmark.bm do |bm|
  bm.report("Array all? and include?\n") do
    iterations.times { subary.all?(&ary.method(:include?)) }
  end

  bm.report("Set all? and include?  \n") do
    iterations.times { subset.all?(&set.method(:include?)) }
  end

  bm.report("Array & and any?       \n") do
    iterations.times { (ary & subary).any? }
  end

end

输出：

       user     system      total        real
Array all? and include?
  2.900000   0.000000   2.900000 (  2.900707)
Set all? and include?  
  0.030000   0.000000   0.030000 (  0.038133)
Array & and any?       
  0.110000   0.000000   0.110000 (  0.112873)

理论上最高效的方法是：

subset.all?(&set.method(:include?))

但鉴于 Set 模块是 Ruby 代码实现的，集合不大的情况下，还是楼主的(arr & subary).any? 实际速度最快

#3 楼 @tini8 uniq 之后还是数组啊，求交集并集还是低效（Ruby 中Array#&之类的求交集并集方法内部是用的 Hash），Set#include? 方法复杂度是 O(1)，数组的是 O(n) 啊

a = [1,2,3,4,5]
subset = [1,2,4]
subset.all? &a.method(:include?)

# 或者
require('set')
Set.new(subset).subset? Set.new(a)

如果求交并集场景较多，还是先转换成 Set 更高效

但是默认进入的第一页确实是个问题哈，或者默认第一页是最久远的评论？用户体验不太好啊。如果要预先读出共有几页，又要多耗计算资源

对了，我的 PlainSite 就是采用倒序字母编号的分页，这样当新文章发布时，旧的列表页面的 URL 不会改变。

因为文章是按时间从近到远排序的，第一页是最新的文章，所以最后一页的 URL 是a.html，倒数第二页的 URL 是b.html。 如果用数字分页，则可以let count = pages.length，第一页的 URL 是page/#{count}，第二页是page/#{count-1}

https://ruby-china.org/topics/22876

同不喜欢无限加载的展现形式！分页大法好！！！！

楼主题叶好像是社区挖坑狂，各大冷门语言的中文社区都被抢注了

#8 楼 @kamehamehon 但是我根本找不到在哪里设置我的 Github

#5 楼 @kamehamehon 还有个 Bug，我在编辑个人技术方向时，它总是将字母小写，我输入“PLT, Compiler ”（注意有个全角的 C），结果是“compiler, PLT, Compiler”

你给出的示例分析的就不太对啊，代码摘要摘的不是他自己的代码：https://github.com/ftao/s5-creator/blob/master/HTML/js/wymeditor/xhtml_parser.js

昨天我还在想，有没有一个社区专门用于批判各编程语言缺点的，比如叫 xlang-sucks.com。因为一般的社区里，只要你说一句哪个语言不好，就会立该被当成 Flamewar，最可怕的是那些 和事老，总是把“没有最好的语言，只看你能不能把它用好”挂在嘴边，昨天也刚看到这篇博客：http://www.yinwang.org/blog-cn/2015/04/03/paradigms/

好好先生

很多人避免“函数式 vs 面向对象”的辩论，于是他们成为了“好好先生”。这种人没有原则的认为，任何能够解决当前问题的工具就是好工具。也就是这种人，喜欢使用 shell script，喜欢折腾各种 Unix 工具，因为显然，它们能解决他“手头的问题”。

然而这种思潮是极其有害的，它的害处其实更胜于投靠函数式或者面向对象。没有原则的好好先生们忙着“解决问题”，却不能清晰地看到这些问题为什么存在。他们所谓的问题，往往是由于现有工具的设计失误。由于他们的“随和”，他们从来不去思考，如何从根源上消灭这些问题。他们在一堆历史遗留的垃圾上缝缝补补，妄图使用设计恶劣的工具建造可靠地软件系统。当然，这代价是非常大的。不但劳神费力，而且也许根本不能解决问题。

所以每当有人让我谈谈“函数式 vs 面向对象”，我都避免说“各有各的好处”，因为那样的话我会很容易被当成这种毫无原则的好好先生。

我最讨厌这种好好先生了

这个，你直接发 HTTPS 请求不就可以了么？

。。。。你只要说 Ruby 中 block 不是 function/lambda 就行了，哪来这么多混乱。在其它语言中 return 都是退出 function/lambda，只是 Ruby 多出了 block，它用的是花括号，像 lambda 但又不是，才产生了混淆

#4 楼 @huopo125 你前面那个“👍”字符是乱码

#2 楼 @huopo125 What?

#5 楼 @Rei 嗯，刚才弄错了

#2 楼 @Rei 这个没办法解码好像

#19 楼 @blacktulip 不服？上 Github 单挑

嗟，来跳坑！

a.sort.join(",").gsub(/(\w),-(\d),\1,\2,?/,"").split(",").each_slice(2).to_a

PlainSite 大法好，退 Jekyll 保平安！ PlainSite: A Truly Hackable Static Site Generator!（https://ruby-china.org/topics/22876）

#7 楼 @chairy11 。。。。。。。。。思维固化成这样？

提交数据就一定得用表单么？

<div contentEditable="true" id="page_content">
<%= page_content %>
</div>
<script>
//每隔三秒就自动保存修改
setInterval(function () {
   $.post({
        content:$('#page_content').html(),
        url:'/save-page-content/'
  });
},3000);

</script>

记得这个项目好像就是： https://github.com/sofish/pen

原来楼主是后端怎么存储没搞明白。这太简单了，随便你怎么存呗，将整个页面的 HTML 存下来