• 是的,一切正常的话没啥必要。我还是想看有没有人做迁移的实践,以及有什么问题。

  • 一下子框架可以替代不少小基建了。不过升级起来的工作量不少啊。

  • Rust2go: calls Go from Rust at 2024年06月26日

    Can Rust compiler change struct memory representation so that Go program can use it directly?

  • 北欧用克朗。大概 1:10。我的重点是欧洲所有消费品真得贵。我的老板们也觉得苹果卖得贵……不过因为统一工作环境用苹果的系统的话,是公司固定资产管理

  • 苹果的笔记本在北欧 3 万左右,真贵。

  • 是的。跑大部分 workflow 都算可以。act 用 docker 跑容器模拟 GitHub Runner。可以下载 JavaScript Action,我能跑的单文件 workflow 都算好用。申请个 GitHub token,然后传 GITHUB_TOKEN,在本机跑起来就很轻松。但是碰到复杂权限,就要重新在 GitHub 上测试了:

    • fix CI
    • fix CI 2
    • fix CI 3
    • fix
    • ci
    • fix CI
    • ...
    • ...
  • 用 act 这个项目可以试着跑大部分的单文件 workflow 了

  • 拼写检查的四种实现 at 2019年03月07日

    BloomFilter 是一个不准的 hash table。

    我要放到语境里说。这个讨论中和应用无关。你说它是一个不准的 hash table。那我们从定义开始看,Hash Table 是一个数据结构,用 hash function 定义一个 K,V 的结构。同时实现了 associative array abstract data type(ADT)。而 Bloom Filter 是一个概率数据结构。首先它没有实现和 hash table 一样的 ADT,你不能取回存的值。它实现的接口大概是给定一个值,能否确定它不在这个集合里面。或者可能在这个集合里面(这是概率论最基本的假设了,概率的基本是集合。所以说是概率数据结构)。然后它是有 false positive 的,这个你已经讲了。结合这两点,这是我前面讲“拿它来和 hash table 类比是不恰当的”。

    当然做拼写检查,讲这些都是多话了。

  • 拼写检查的四种实现 at 2019年03月06日

    Bloom Filter 是 Probabilistic data structure。分清这个概念就更好理解了。既然是概率,那就不是确定的。要求概率模型做确定性的事物是在本质上无视它的属性。所以拿它来和 hash table 类比是不恰当的

  • Ruby v2.4.2 Released at 2017年09月15日

    An incompatibility has been found for Ruby 2.4.2. Ruby 2.4.2 can not link with libgmp nor jemalloc.

    这样的话过几天要出 2.4.3 吧...

  • GSoC 只有学生能做,我在学习。

    @istrwei 我不确定他们会这样招人。开源项目的做法大概当初给 Atom 贡献多了成员工这模式一样 https://www.discourse.org/contact

  • 我并没有做全职,我从来都是义务做的。跟着他们做了两次 GSoC 和一些项目。作为导师的话,他们沟通都很友好。基本上也是我想做什么都让我做下去了

  • 好,写了个列表。如果要当做职业方向的话,还是认真看一遍吧。

  • Rails 的后端不支持转换到拼音的 transliteration,因为它用了个字典,里面根本就没有这个数据。 有一些拼音的 gem 你可以用。 ICU 没有很好的 ruby 绑定的库,但是 ICU 是能很轻易的做到这个的。(这些数据都在 CLDR 这个项目里)

  • 最近重新捡起了这个事情,花了一周的时间研究了下。写了一个验证性的实现。Unicode 正规化的效率大概能快 500% https://github.com/fantasticfears/icu4r-next 编译要依靠本地有 icu 的头。把 ICU 链接成静态库很简单,不过还没做。现在暂时写到这个地步,我好像没有动力继续下一步了...欢迎提问。

    Unicode 相关的用途和 CJK 用户应该最有关系了,日本社群实现了 CSI 后大概已经不理会处理国际化的问题了...(SHIFT_JIS 是 Unicode 史前编码,转到 UTF-8 可能有数据丢失,by Yehuda) 但是日子还是得过下去。ICU 提供的功能很多,transliterate, normalize, converter, collate, spoof_checker,Unicode 标准里提到的算法都有。twitter-cldr-rb 和 ICU 都用了 Unicode CLDR 的数据,只是 twitter-cldr-rb 用 Ruby 实现,而 ICU 是 C/C++/Java 的实现。不过我实在不想重新造轮子,所以一直想写胶水实现。

    我没想到写这个插件这么困难。MRI 内部太太太可怕了。写插件困难的地方在于 MRI 没什么文档,内部 API 随便用,毫无边界,要找到对的 API 就很麻烦了。

    然后是编码问题。MRI 的字符串一定是 byte array 加上每个字符串额外存储的编码信息。而 ICU 大部分情况下处理的是 UTF-16,所以一定要转换,为了能控制清楚编码,只好在 C 里面写。ffi 的 API 实在难以处理这种复杂的状态了。

    最后内存管理,为了转换编码写了 UChar String 的一个内部类,把 C Struct 包装到 Ruby 类(Ruby 内部有个 Data 的类,BigNumber 也用了这个)。这样既可以用来调用 ICU 的 C API,也可以靠 Ruby GC 来管理生成的内存(MRI 在 C 这个层面是扫寄存器!和栈来追踪有没有东西需要清理)。原来的 icu4r 这个库把类似功能包装出了一个真的 UString 类,用来存 Unicode 字符串,这个库的历史都在 1.9(CSI model)之前了。现在的 String 类功能丰富,做个内部类方便做胶水就好,放出来八成没什么用...

    附写插件比较有用的参考:

  • Discourse 1.6+ 有启动向导了,手动创建管理员也没法跳过。

    run:
      - exec: echo "Beginning of custom commands"
      ## If you want to set the 'From' email address for your first registration, uncomment and change:
      ## After getting the first signup email, re-comment the line. It only needs to run once.
      - exec: rails r "SiteSetting.has_login_hint=false"
      - exec: rails r "SiteSetting.wizard_enabled=false"
      - exec: echo "End of custom commands"
    

    在 app.yml 的 hook 里还是可以禁用相关的设置的。这和管理面板里操作的一样。

    SSO 过去的用户名也会被洗一次,有些符号或者中文会很惨...

    最后,Discourse 现在支持 SAML SSO 了。https://github.com/discourse/discourse-saml

  • 还有位置吗,有位置我也跟你们凑热闹一起住 XD @lgn21st 这个房主应该是不喜欢吵闹的...

  • Getting started with JRuby at 2016年04月17日

    我在想是不是 Gradle 这样的工具更能有效地管理依赖和启动呢?

    JRuby 的巨大优势之一也是无数的 JVM 库,这些库被打包、测试和分发到 Maven/jcenter 上。重点如果是利用这些库的话,未必 jbundler 等是一个很好的办法

  • #85 楼 @geekontheway 为什么后面请求的是淘宝的 API 呢?


    回源的时候的延迟,gem 一多特别容易让 bundle 中断,部署的时候带上 --retry 加上应该会好一些。 阿里云部署 Discourse 的时候大概因此中断了 3 - 4 次,但是问题很奇怪,有的时候是 gem 下载问题(看起来像回源失败),但是之后再执行 gem update bundler 也因为下不到 spec4.8 失败了(这肯定就不是回源的问题了)。倒是 DigitalOcean 都只中断了 1 次,谜一般...😓

    因为不断失败,所以开始走查问题。以下尝试来自于阿里云上海的 139.196.41.197(ipip.net)机器按照 https://gems.ruby-china.org 这个 URL 部署 Discourse 碰到的错误(生产环境部署)。

    例子:

    第 2 次重试失败(FetcherError 和 GemspecError,应该是 CDN 回源的问题):

    Bundler::GemspecError: Could not read gem at /var/www/discourse/vendor/bundle/ruby/2.0.0/cache/redis-3.2.1.gem. It may be corrupted.
    Bundler::GemspecError: Could not read gem at /var/www/discourse/vendor/bundle/ruby/2.0.0/cache/msgpack-0.5.11.gem. It may be corrupted.
    Gem::RemoteFetcher::FetchError: bad response Bad Gateway 502 (https://gems.ruby-china.org/gems/rb-fsevent-0.9.4.gem)
    

    第 3 次重试失败(API 失败,SSL 签名错误;但是之前的 24 次请求没有问题):

    could not fetch from the dependency API, trying the full index
    HTTP GET https://gems.ruby-china.org/quick/Marshal.4.8/actionmailer-4.1.10.gemspec.rz
    Could not verify the SSL certificate for
    https://gems.ruby-china.org/quick/Marshal.4.8/actionmailer-4.1.10.gemspec.rz.
    

    第 4、5 次重试失败:

    ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
        server did not return a valid file (https://gems.ruby-china.org/specs.4.8.gz
        bad response Bad Gateway 502 (https://gems.ruby-china.org/specs.4.8.gz)
    

    既然不是回源问题,那么重新回到 CA 证书这个点上。按照 issues 给的链接从 https://curl.haxx.se/ca/cacert.pem 导入证书链,再指定环境变量。(缺点显而易见,公钥的 integrity 没有保障。不过这是目前的一个让源能用起来的 hack)

    然而重新回到了 4、5 次重试的时候失败的问题。虽然仍然不排除阿里云的链接问题。但结合其他人碰到的问题回到镜像的部署问题,还是应该探索下解决的办法,故已提交 issue

    http 的环境下 bundle 是成功的,不过 Discourse 相关 gem 花了 18 分钟。

  • 打算大概先自己测试一下看看坑,然后把 Discourse 的淘宝源改到 Ruby China 源。

  • rack-mini-profiler 的用途是能直接找到线上的页面的相关性能信息,但是其中也有很多服务器内部的一些安全信息,比如说 session 和 cookies 等。在 ?pp=help 中的内存相关的分析,基本上会暴露 Rack session。

    这些信息对开发者还是足够安全的。

    再加装 flamegraph 后更可以直接可视化分析热点。

  • #3 楼 @luikore Ruby 这个 binding 其实也是很麻烦的。大部分的功能,用 C 再对接,写法及其特别的啰嗦。UChar 这个地方如果用 C 写,那么 FFI 就不可能再用了。OS X 这些系统没有 ICU 的头文件,所以起码还得解决各种头文件和版本的问题...

    FFI 没大问题的应该... 不过写 C-ext 执行更快一点,而且 FFI gem 本来就是个 C-ext

    我找过几个 benchmark,ffi-icu 的速度相当没有问题,这也是我比较想继续用 FFI 的原因。

    实现一个 UChar byte array 作为 ICU 和 Ruby String 的 adapter,简单的实现考虑到复制也并不会很快... ICU 这还有很多自动的类,还做了 cow 的,比如 UnicodeString。这些都没有 extern 给 C,所以 Ruby 的话写 C extension 也不能用...

    另外的选择像 Rice 还是不够成熟,原来踩过坑吃过苦头。

  • FFI 没大问题的应该... 不过写 C-ext 执行更快一点,而且 FFI gem 本来就是个 C-ext

    速度上确实如此。FFI 的包装主要在于方便,大部分关于 ICU 的操作只有几个函数调用罢了。除了字符串这部分,看起来是 FFI 最节省时间。而且不用像 icu4r 那样写 n * 1000 规模的 C...

    ICU 在日常使用中,系统有的概率不低,这也是用 FFI 的一个优点吧,不用下一个很大的库,也不用再编译了。

    从 UChar* 生成 Ruby 字符串,可以直接调 Ruby 的 CAPI rb_str_new(uchar_pointer, uchar_length * 2)

    然后在 Ruby 中 str.force_encoding('utf-16le').encode('utf-8')

    UChar 可能是 malformed 的 UTF-16,所以这部分还可能出错,当然作为 gem 内部使用基本不会遇到。但是大小端序这样写似乎是大问题啊...容易碰到跨指令集的问题

    最后我有个不情之请,我实在看不懂 Haskell,你知道 Data.Text.ICU 大致是什么做法么?

  • Grunt 是一个 task manager,作为 pipeline 有很多问题。Ember.js 社群在构建 ember-cli 的时候使用了 broccoli 构建 pipeline。可以单独使用也可以配合 grunt。

  • 求 Ember.js 开发经验的分享 at 2015年03月26日

    #26 楼 @teddy_1004 @nightire Discourse 没有用 Ember-data 是因为那时候 Ember-data 官方强烈建议不要使用。能迁移肯定会迁移过去的,不过要花很长时间。可以看到 active_model_serializers 0.10 就会按照 JSON:API 标准来序列化对象了。而 Discourse 这现在只好用老版本。

  • 恭喜,结婚真是最棒的事情,平淡中不平凡。

  • Discourse 中文完全安装指南 at 2014年12月20日

    我建了论坛来做 Discourse 本地化的支持。 https://meta.discoursecn.org/ 不过 Rei 所说的托管服务,似乎在国内比较难过备案关卡。

    @touzi 两份指南。 https://meta.discoursecn.org/t/30-digital-ocean-discourse/26 https://meta.discoursecn.org/t/zai-da-lu-di-qu-de-yun-shang-bu-shu-discourse/28

  • 可以在 Console 里检查一下有没有错误。 Article.elasticsearch.create_index! force: true Article.elasticsearch.refresh_index! 详见 README

  • #4 楼 @billy 第一句话没看懂。目前最多的 plugin 是 SSO,会自带的是 Poll,用于投票。

    我没写 plugin。一般说的是现在的 Plugin 还有很多没有做的:

    1. 更改数据表而非只用 PluginStore 和 Redis。
    2. Sam 的一大段
    3. 现在 EmberJS 的模板插件不能改真的很不舒服。