是的,一切正常的话没啥必要。我还是想看有没有人做迁移的实践,以及有什么问题。
一下子框架可以替代不少小基建了。不过升级起来的工作量不少啊。
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 上测试了:
用 act 这个项目可以试着跑大部分的单文件 workflow 了
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 类比是不恰当的”。
当然做拼写检查,讲这些都是多话了。
Bloom Filter 是 Probabilistic data structure。分清这个概念就更好理解了。既然是概率,那就不是确定的。要求概率模型做确定性的事物是在本质上无视它的属性。所以拿它来和 hash table 类比是不恰当的
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 这个房主应该是不喜欢吵闹的...
我在想是不是 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。
#26 楼 @teddy_1004 @nightire Discourse 没有用 Ember-data 是因为那时候 Ember-data 官方强烈建议不要使用。能迁移肯定会迁移过去的,不过要花很长时间。可以看到 active_model_serializers
0.10 就会按照 JSON:API 标准来序列化对象了。而 Discourse 这现在只好用老版本。
恭喜,结婚真是最棒的事情,平淡中不平凡。
我建了论坛来做 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