好巧不巧，今天刚好有人在 Crystal 论坛提及 mojo.

https://forum.crystal-lang.org/t/mojo/5627

好久不关注排名了，大感意外，竟然超过了 BASH, Elixir, Erlang.

这个薪资，还要求 <口语流利必须流利（不要求口语多标准，只要能够互相听得懂，互相谈笑风生就没问题）>, 个人认为只能招一些菜鸟程序员了。

当然，也可能是我不太了解现在的行情，毕竟欧美大厂都开始裁人了，僧多粥少，卷的很。

但是我是有比较的，六楼提到的那家公司，我之前工作了一年多，按照那时（19 年的标准），比这家公司好很多。

話說在那條推上看到了熟悉的 ID……

难道楼主说的是我？哈哈

似乎 Rails 6 的 ClassLoader 抽成接口所以可以替换了。

是的，好像有一个配置，可以选择使用老的 Module#const_missing 实现和新的 zeitwerk 采用的 Module#autoload 实现。

扯个题外的，我之前和 @dsh0416 讨论利用这个和 Bootsnap 的原理做 Ruby 代码的预编译，甚至加上简单的 AES 加密，用来保护外包之类项目的源码

👍

自己的简单介绍换成了英文。

抱歉六年半后，挖了我自己坟贴 ......, 前几天在网上找到了一段 10 年前的 blog 文章，发现了解决类似问题的 lisp 代码，然后今天改了改，现在工作的蛮好，有用到的请自取吧。

@msg7086 , 我承认你说的大部分都是对的，反倒是我第一时间看到你的观点时，对你的有些话有些误解，这里我道歉。

其实我也用很多 GUI 工具，dbeaver 用来连接数据库，beyond compare 用来目录同步，文件比较，只是更倾向于不依赖于这些工具而已，可能是目前我的操作方式够用，没有更多的需求的缘故，如果到那个地步，又有足够易用的，让我心动的工具可用，我也会选择他。

对了，你提到你用了 update_base dev，请问这玩意儿支持 3-way merge 吗？能做成左 + 中+右 diff 界面吗？能高亮显示段落差异和行内差异吗？

以前用 Beyond Compare 执行 3-way 合并，现在也会在提交代码前，用这个工具 code review 一遍。

但是后来发现，其实不好用 (可能 bc4 这方面比较弱吧，常出错), 最快的方式反倒是直接用编辑器逐个文件编辑来的最快.(这也是 Ruby China 社区一个大牛曾经提醒我的，直接搜索 <<<<<<, 自己编辑解决冲突，效果不错)

本来只是来顶楼主小哥的，没忍住，歪楼了。

我不完全是这个意思，但是我觉得该说的我已经说了，能理解的人也应该已经理解了，不能理解的人不管说什么大概也不会理解，所以我不想再翻来覆去重复那些话了。如果大家想继续讨论的话当然没问题。如果有人还想杠的话我就直接 Block 得了。时间宝贵，不想浪费在无谓的争吵上。

我的观点是任何一个对 Git 有比较复杂需求的人都应该用 GUI 辅助而不是裸撸 CLI，从来不会犯错而且手速飞快 or 闲得没事干的人除外。

困了，睡了。

好吧，本来不想再说了，因为很多原因，我虽然加入 Ruby China 好几年了，也不常来，但是实在是不能忍了，从一开始，你定调的口气

Git 你需要一个牛逼的 GUI。光用命令行，几乎干不了什么复杂的事情。

我觉得就已经把整个 Ruby China 社区受众的理解能力的 level 降低了不止一个档次，这种话如果你实在一个 巨硬 产品主导的社区发出来，可能会大受赞赏，但是却偏偏在一个命令行操作挺多，而且 Ruby 语言本身其实和 CLI 很有渊源的一个语言之上谈这个，就有点小瞧社区的大众了。

我说的是 用命令行，几乎干不了什么复杂的事情，主语是人，说的是人类的能力无法达到充分利用命令行赋予的功能。

我只能说越解释越黑，很明显你也拉低了 linus 的智商，你写这么复杂的 git 功能干嘛？是让人用的吗？

但是我觉得该说的我已经说了，能理解的人也应该已经理解了，不能理解的人不管说什么大概也不会理解，所以我不想再翻来覆去重复那些话了。

我真的觉得，只有你自己在认为，和你争论的这些人不理解。

如果大家想继续讨论的话当然没问题。如果有人还想杠的话我就直接 Block 得了。时间宝贵，不想浪费在无谓的争吵上。

好吧，也许你时间宝贵，但是你不这样自我的将自己的那一套 GUI 工具当作使用 git 的救世主来这里传教，没人愿意花费时间和你争论。

请问你最后的图每次合并分支都是通过 rebase 吗？能分享下你们是按照怎么样的流程走的呢？

这位小哥，我猜的没错的话， @msg7086 在合并代码前，会要求 feature 代码的开发者，做 rebase 然后重新强推一下。

假设，你要合并 feature/new_feature 到 dev 分支，你需要首先 checkout feature/new_feature 分支，然后运行 update_base dev(参见之前回帖写的那个函数), 解决冲突 (如果有), 然后强推 git push --force origin feature/new_feature

emacs 的 magit 算 git 的 GUI 吗？

这玩意儿超级强大的，因为太强大，所以我一直没敢用，还在用一个很老的包 (git-emacs) + 自己的 hack,

我说的是 用命令行，几乎干不了什么复杂的事情，主语是人，说的是人类的能力无法达到充分利用命令行赋予的功能。

感觉这个还是反的，最复杂的事情，都一定要通过命令行来自动化，如果 git 的标准命令你觉得有点麻烦，你可以写个 bash wrap 起来，我自己写了大把的类似的脚本，只是为了让我操作 git 时提供便利，这就是为什么有了 git, 还有 git-flow, 有个 docker, 还有 docker-compose.

客观而不带任何偏见的讲，如果你的话是对的，Linux/BSD/Unix 真的没有存在的必要了，每个人工作方式不一样，你喜欢 IDE, 习惯工具，却认为别人用命令行干不了复杂的事情，有点以偏概全了。

为了增加信服力 (不是我信口雌黄), 贴一下 git 相关的脚本目录：(虽然不是每个脚本都常用，其实就是心血来潮，写个脚本，当作笔记而已)

 abort*               cob@       fork*    gitb*                      gitdiff@                    gitll@                         gitv*           push*           skip*
 add*                 cofile*    fork1*   git-bcompare*              gitdiffc@                   gitls*                         gitzip@        'push!'@         stash*
 add_key_to_github*   com@       gc*      gitc*                      git-diff-wrapper*           gitls1@                        merge*          rebase*        'stash!'@
 anno*               'com!'@    'gc!'@    gitcat*                    git_find_big_files*         gitm*                          merged*         rebase_log*     stashp@
 clean*               commit*    gca@     git_clean_merged_branch*   git_find_blob_commit*       gitrm*                         merge_dev*      reflog*         submodule*
'clean!'@             cont*     'gca!'@   gitcp*                     git_find_dangling_object*   gits*                          merge_ours*     remote*         swap*
'clean!!'@            cor@       gcp*     gitd*                      git_find_delete_file*       gitsize*                       merge_theirs*   reset*          track*
 clean1@              cov@       gd@      gitd1@                     gitfsck*                    git_squash_branch_to_commit*   mergetool*     'reset!'*        unreset*
 co*                  drop*      gd1@     gitdc@                     github_create_repo          gitss*                         pop*            show*           up*
'co!'@                fetch*     gdc@     gitdd@                     gitinit*                    gitsub*                        pull*           shown*          upa@
 coa@                'fetch!'@   gg*      git_delete_big_files*      gitl*                       gittar*                        pullups*        show_restore*

再贴的你应该懂的最常见的命令：

function update_base () {
    branch=${1-develop}
    git checkout "$branch" &&
        git pull origin "$branch" --rebase &&
        git checkout - &&
        git rebase "$branch"
}

咳咳，我觉得你说的的确是反的，只有 UI 做不到的，没有 命令行做不到的，UI 都是调用命令行。

下面是普通的 git 命令行输出，不是一样有你截图的效果？(添加 --graph 参数即可)

 1  *   16299e9 - (HEAD -> develop, origin/develop, origin/HEAD) Merge branch 'release/1.6.0' into 'develop'(29 hours ago,tracy)
 2  |\
 3  | * 38cd519 - (origin/release/1.6.0, release/1.6.0) 🐛 修复feed物理删除引发的问题(29 hours ago,tracy)
 4  | * b890266 - Fix clazz.grade bug(30 hours ago,Billy.Zheng)
 5  |/
 6  * c9efa4f - update graphql_controller(31 hours ago,Billy.Zheng)
 7  * 54142be - refactor graphiql_basic_auth(31 hours ago,Billy.Zheng)
 8  *   1fd379a - Merge branch 'feature/update_1.8' into 'develop'(31 hours ago,Billy.Zheng)
 9  |\
10  | * 2c408a8 - (origin/feature/update_1.8) comment test(31 hours ago,Billy.Zheng)
11  | * 6417971 - refactor feed_connection(31 hours ago,Billy.Zheng)
12  | * 32e8141 - Fix test(31 hours ago,Billy.Zheng)
13  | * 738b3be - Add schema.grahpql(32 hours ago,Billy.Zheng)
14  | * 74a538a - delete recruit_image api(32 hours ago,Billy.Zheng)
15  | * 0aaa961 - delete delete_image api(32 hours ago,Billy.Zheng)
16  | * 8ee8140 - update fields to 1.8(32 hours ago,Billy.Zheng)
17  | * 54b3428 - fix query name(32 hours ago,Billy.Zheng)
18  | * b7a59f9 - remove all require in graph folder(32 hours ago,Billy.Zheng)
19  | * 19553b6 - replace @context to context(32 hours ago,Billy.Zheng)
20  | * 456cfa6 - replace @object to object(33 hours ago,Billy.Zheng)
21  | * 03789db - remove loaders require(33 hours ago,Billy.Zheng)
22  | * 38457a6 - update enums(33 hours ago,Billy.Zheng)
23  | * d8fab81 - move global constant to initializer(33 hours ago,Billy.Zheng)
24  | * e909d23 - Update sequel config(33 hours ago,Billy.Zheng)
25  |/
26  *   f508b67 - Merge branch 'release/1.5.0' into develop(33 hours ago,Billy.Zheng)

这个帖子必须支持！

我们也招聘 Ruby 工程师哦。

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

针对公司 Ruby 方面的技术细节，我再做一些补充：

1. 我们毫不吝啬的，并且持续不断升级或使用最新技术，GraphQL, Sequel(更快的 ActiveRecord), Rails 5.2 哦。
2. 我们使用 TDD(虽然不见得总是测试优先), 开发过程中，代码持续重构进行中。
3. 我们正在逐步拆分到微服务架构，因此，会有很多机会，拆分出一个单独的项目或 Gem, 独立部署，独立运行。

我们是一家很新的公司，虽然我们开发进度很紧张，但是 TEAM 每个人很有活力，遇到问题也决不妥协，不将就， 加入我们，你一定你会有一种不一样的感觉。

欢迎大家踊跃面试交流哦！

支持一下！

酷酷酷～ 说得真好！

报名。

就我了解，以及这几年所见，绝大多数人是不肯在编辑器上多花时间的。

我是用了多年之后，把一些之前高度定制的快捷键回归默认了，但这绝不是因为默认的好，只是考虑在别人机器上操作，线上部署，等等一个折中操作尔。

最后说一句，你竟然不 map capslock 和 Ctrl，👍

@jakit ，查了下，memorize 早就停止开发了，最新的，基本上不怎么维护的 gem 叫做 memoist

@jakit 只是在说他自己的想法，像我这样一个外行人，一样看的很 high, 对不对，反而不重要了，自己也会有评判的标准，对吧？

Ruby 离开 Rails 什么都不是，没什么好说的

不敢赞同

To @nong , @jasl , @tony612 , @killyfreedom ,

我只是发这个贴玩玩，对我没有影响的啦，没有 Rails, 我照样用 Ruby.

但是 Rails 是后端框架，前端本来就只能写 JavaScript。

其实这话也不对了，这里有一个很新的项目： http://ruby-hyperloop.io/

我已经参照 Tutorial 写了一些代码了， http://47.89.26.177:8084/ 这是线上的一个。大家可以体验下. github 代码：https://github.com/zw963/hyperloop-rails-helloworld1

最近维护者们在录视频，稍后可以发出来大家看。

我现在右手边坐着一个 38 岁的大叔程序员，股票交易平台的技术骨干，需求、开发、运维、运营都得管理和支持，前端、后段代码，什么 php、java、shell script、obj、swift、javascript/css/html，都得看。还得应付日历上画满的会议。一天从早忙到晚，还是抽空用 ruby+rails 写了一个项目，现在已经上线了。他从来没有用过 ruby 和 rails，也请教我一些很平常的 ruby/rails 的问题，但是基本上自己撸完的。代码我看过，写得不咋滴，但是能说明什么呢。

哈，这么老的帖子竟然有人回复。

怎么说呢？我见过你说的类似你提及的类型的程序员，我总结下来就两种：

• 非常聪明，但对职业没有兴趣，混日子，这种大多数。
• 非常忙，迫于压力，实在没时间推敲，其实很多都是当 CTO 的。

但结果 (至少某个阶段) 都一样，看他们很累，真的很累，写代码只图快，又懒得写测试， 对于 TDD 完全不感冒，更别提 JDD(Joy Drive Development) 了，他们的工作模式 多数都是：先快后慢, 总体上来看，修 Bug 时间远多过 创造客户价值 的时间。

毫不夸张的说，五年来看，也许我不如你们，十年来看，大概这种类型的，一定不如我。

顺便说一声：我也是大叔级别的。做开发五年了，比你同事还要大上三四岁，但从你对他 的描述来看，我目前不如他。

@jasl , rust 1.8 开始支持交叉编译了。下面是一段文档：

Since Rust 1.8 you can install additional versions of the standard library for different targets using rustup/multirust.
      For example:
      $ rustup target add x86_64-unknown-linux-musl
       Which then allows for:
       $ cargo build --target x86_64-unknown-linux-musl

不知道这是不是意味着，如果知道目标部署机器的架构，例如：server 是 X86_64 架构，开发机也是， 我是否可以本地编译好 rust 库文件，直接部署到目标服务器开始使用？

如果可以实现，我想首要的好处，就是不需要在目标机器安装编译环境，虽然文件可能会大一点， 但是对于只在部分核心 (较少的地方) 的部分使用 rust 的项目，还是很有优势的。