• 还是进程隔离好,ruby 多线程并不强。多进程也不是想象的那么耗内存。

  • 人家都是 SPA

  • 就目前人才市场来说,前后端分离会令一般开发人员比较好理解。但其实你想想在没有前端框架的时代,公司也是有专职前端的,这一点并不矛盾,也就是说用传统 Rails 一套也是可以引入前端开发的。

  • 流畅度参考 Basecamp,Stimulus 的示范,速度非常流畅。另外 Basecamp 也打包了 app。我自己的体会是前后端分离在很多时候是一种负担,直接把 Web 开发升级成了 App 开发。在一些强交互的地方局部使用 Vue/React 是我比较偏好的做法。

  • 直接招人,要求用 Rails 即可。此外,没有特别原因搞前后端分离的话,是会增加投入的。Rails 开发效率高,就是因为是个通吃的框架。富前端,不妨考虑 Stimulus?

  • 远程工作为哈还未普及 at 2019年08月14日

    带头的蠢吧,需要高度协调一起踩坑

  • 广告做的差,领头的是日本人,不擅长在欧美推广

  • 顶楼是错的,要讨论再开一帖吧。

  • jekyll 或 wordpress,自己写功能差远了

  • grep/rg 玩的转,没啥问题

  • 我也是 Linux 很久最后转 Mac/Win 了。Linux 从 Fedora Core 5 开始折腾,经历过 Fedora,Ubuntu,Arch,Suse,都是做过主力桌面的。发表下个人观点:

    桌面系统我们需要一个成熟稳定的东西,来把精力放在更重要的事情上。使用这个桌面的用户和为其开发的开发者数量将是硬指标。在这一点上,Win 远大于 Mac 远大于 Linux(桌面)。但是在开发者领域 Mac 和 Win 的比例就没有那么悬殊了,具体不好说。选 Mac 的理由就是 Unix 系统外加完善的 GUI。其实 Mac 也有不稳定的时候,比如 macOS 10.11 和 10.12 对 4K 屏幕兼容性问题(鼠标指针漂移)就困扰了我好几年。但总的来说 macOS 我从 10.6 用下来,基本稳定。尤其是在电池、温度、功耗上的平衡是令我想当满意的,尤其是 Haswell 之前是别家两倍的续航,那真是提前进入下一个时代。

    从硬件性价比上,mac 的确不是最佳的。但是这一块通常不是太大的问题,因为一来生产工具预算充足一些,钱也买不来稳定 GUI+Linux 跑在 Windows 笔记本上。二来如果考虑到某些因素可能性价比不是那么差,例如 iMac 的 5K 广色域屏,如果单买也很贵。

    另外,作为开发肯定推荐 Pro,目前的话,用的 8 代,13 寸性能也很强劲,轻薄程度还不错吧。像我手里的 2014 款的话,当年的 13 寸,低压版 CPU 性能就要比标压差很多。

    从软件上来说,说到动画,这个就是适应。有人觉得炫酷,有人觉得烦,但没必要太纠结。实际上 macOS/iOS 的设计理念,动画往往是给人以提示作用,而非酷炫,只是别家图形界面用文字的,这边改为动画了而已。这一点我是 iOS 开发多年,这是他自己 HIG 说的。

    快捷键方面,我的看法也是适应大于更改。mac 快捷键是有不少槽点,比如我以前 Photoshop 每天按一万次的 command option shift s,这就一点也不 “快捷”。但是系统没有完美的。我在做移动开发那几年,需要同时操作 vim 来写后段代码,Xcode 来写 iOS,Android Studio 写 Android。而我因为 IntelliJ Idea 用过一阵子,快捷键又是默认的,所以我脑中同时要在三套快捷键之间切换。这三个工具基本鼠标都是配角这个大家应该没意见。是的很繁琐,甚至有些变态,但是回想下,能最有效同时运行这三个的,只有 mac 系统。那时候甚至 windows 的 Android 模拟器执行效率都大不如 mac,后来才赶上。

    我有理由相信,macOS 是除 Windows 开发外的首选系统。

  • 我们一般就是花式 rg、awk、甚至 ruby 来搜索。搭建日志服务需要花费一些精力,也需要额外时间维护

  • 对比度太低,界面不同功能区域不突出。整个界面全白晃眼睛,毫无品牌辨识度,貌似是自大到不需要?

  • 本身的重启是使用 unicorn 的 USR2 信号进行无缝重启的,唯一的问题是等待时间。要排查这个问题,你需要了解 unicorn 无缝重启的过程。

  • macOS 安装 Ruby 报错 at 2018年11月07日

    please read /Users/shan/.rvm/log/1540623603_ruby-2.5.1/configure.log

    这个日志你可以分析下

  • Ruby 的好朋友 -- jemalloc at 2018年11月05日

    我这个帖子里提到了 M_ARENA_MAX 默认值的变化(从 2 到 2 * CPU 核数),有人怀疑是 red hat 为了讨好大用户(通常拥有足够的配置)所以用空间换性能。最后页面下方 sidekiq 作者和 Sam(一开始 jemalloc)的倡导者也都达成了一致,认为 malloc 和 jemalloc 的区别的原因是他们默认参数的不同。换句话说 malloc 如果设置了 M_ARENA_MAX = 2 也可以达到 jemalloc 的评测性能。因此两者并没有所谓的性能上的明显区别。

    持谨慎态度的人并不仅仅是认为 jemalloc 会带来问题,而是如果不能证明 jemalloc 确实更适合 ruby,那么就没必要作为默认选项(本帖的讨论内容)。毕竟这不是一个小的改动。

  • Ruby 的好朋友 -- jemalloc at 2018年11月04日

    https://bugs.ruby-lang.org/issues/14718 在这个里由后续。结论是 malloc 的问题是在 glibc 在某个版本开始某个默认参数发生了变化,如果调回去就跟 jemalloc 差不多了。而 jemalloc 不同版本表现也不尽相同,无非是时间和空间的取舍。最后大家一致认为最佳解决方案是调整 malloc 的那个参数,因为对于 ruby 的场景更为适合。

  • break if str[v+=1] != 3
    

    不是可以吗

  • [上海] 已关闭 at 2018年10月12日

    sass?saas?写错了?

  • 新出现的东西没看出来哪个解决了 Rails 没有解决或者解决的不足的问题。至于 react,vue,前后端分离,这些跟 rails 又不矛盾。

  • 目的不太一样。Model 里能做更复杂的验证,有友好的报错。数据库是为了在守住关键底线,限制功能要弱一些。

    如果你这个字段,不存在并发访问等绕过 Model 的情况,你可以不做数据库层面限制。

  • 方法调用,还有 lambda, proc 等,在 Ruby 里是不一样的东西。至于为什么这样设定,这是作者是这样想的。对我个人来说,没有什么好与不好。如果与 JS 等语言比,方法、函数、lamba 其实就是一个东西,确实是更一致,但是 JS 也有 JS 不一致的地方。

    实际上,Ruby 因为有 block 的存在,很多时候并不像是 JS 一样,是函数传来传去的,它是传 block。以你的例子(我帮你格式化了,不知道是不是你本身的意图)

    tt = ->(fn, arg) {
      fn.call(fn.call(arg))
    }
    
    aa = ->(arg) {
      arg << '!'
    }
    
    tt.call(aa, 'ok')
    

    首先在 Ruby 里我们可能不太会去定义高阶函数,而会去使用一个私有方法。在我接受高阶函数的概念后,我也尝试在 JS, Scala 里用高阶函数来封装局部逻辑,但是事实证明是这带来了代码可维护性的降低。因为本身这种需要局部高阶函数的函数,逻辑就很复杂,这时候使用高阶函数,相对于另一个私有方法,本身就在增加复杂函数的长度。

    如果我把你的 tt 当成是一个方法,而不是一个高阶函数,那可以这样写:

    def tt(arg)
      yield(yield(arg)) # 这里我不清楚你的意图,一般应该不会这样做,我只是复制你的逻辑
    end
    
    tt('ok', &block) # block是这个调用tt的方法的一个block参数
    

    是不是相对你的版本好看一些?

    JS 里的

    var hide = function() {
      // ...
    }
    

    本来在 Ruby 里,我们就会用一个方法来代替的,所以就基本不存在你说的连环a_lambda.call()的调用。

  • Ruby 3.0 现在动向如何?有什么进展?对于实现 3x3,目前采取了哪些优化方案?

  • 人工的智能识别

  • Linux、Ruby 不冷没天理! at 2018年02月09日

    苹果支持 DP 1.2 Multistream 有问题,从 10.9 一路拖到 10.13,还给我发邮件说 “修好了!” 结果带来更多问题,到现在 10.13.3 还没修完