• 他这里面东西太多了,运行起来你看多少个进程。考虑到可延展性架构很复杂。其实如果你只是要个仓库,就放个裸 git,issue 管理外面用个免费的比如 youtrack 就行了,如果你不需要很多功能的话

  • 建议 ruby 换吉祥物 at 2023年12月06日

    不要换,ruby 就是硬

  • 以下仅代表个人经验:

    用 hotwire 的时候,不免会思考,这个交互是放在服务端还是客户端。这点界面变化,我是为了渲染接口统一走后端,还是用 dhh 的 stimulus 在前端搞一搞?

    实际使用下来,vue 2 那种模式是最方便的,把他当成一个强效版 stimulus 就可以了。hotwire 拉 html 不够的时候,自然的引入一个 vue 2 做前端渲染,保证最大的灵活性。

  • DHH 肯定是在宣传自己的理念了。前后端一体是个好的想法,只是某些时候可能会比较费脑子。举例说,我有一个 3 个标签页的结构,如果用 hotwire,还得纠结一下这三个标签是一次渲染出来还是分批渲染。分批我还得搞 3 个 action 这种事情。React 则胜在简单粗暴,上就对了。

    至于打包开销,自从有 esbuild 后,一切都很轻松愉快。第一次从 webpack 换过来,真的是把一分钟的时间缩到了 2 秒内。

    我倒是希望前后端一体话可以有更加容易理解和执行的解决方案,能让 Web 开发更加简化。

  • 你怎么看出来这里的人都沉睡着?人家问 rails 有没有技术优势,又没问怎么挣钱。人生导师当惯了?

  • 仍然具有极大优势。借鉴的那些你用下就知道了,只学了点皮毛。光一个 orm,别的借鉴的都缺胳膊少腿的,比如 migration 有限制,没有自带,不给脚本等。以及不给测试。这都还是 mvc 的一个 m,其他两个都还没提到,更没有提三个结合在一起,外加后面经典几个 gem 带来的巨大生产力提升。

  • 拿起键盘,复制粘贴,就是干

  • 111 at 2020年11月14日

    java 也不是默认性能就强,都是要好好调教的。ruby 做项目一样,都是要想办法的。这不能证明是语言性能的差异。

  • 1.9 开始就 vm 了。我估计你是在思考一些不存在的问题,就是 java 里面 jvm 垃圾回收是否效率高,jit 是否牛逼等等等。ruby 世界里不是这么解决问题的。

    不否认多线程模型是有用的,但是现实里很多时候多进程就搞定而且更好。另外 ruby/python 这边本来高性能部分就是要上 C 的,不是想做 java/js 那种全家桶。说白了 java/js 想替代一切那都是为了宣传,至于要干活,办法可以有很多,条条大路通罗马。

  • benchmark 这个 gem 没用过吗

  • 同意 1 楼的。

    第一,花括号和 do end 这个从没有思考过程,就是单行/多行 第二,if 这个,写 if 的时候我思考方式是这样:要么是情况比较简单,我就会想 if a 则 b,这样就看这个 a 是不是足够简单,如果是就写单行,不是就考虑多行。否则我就是 if esle 先铺好,再填内容。无论哪一种我不会纠结单行还是多行。

    关于以上两点,还有一点可提的是,ruby 这些功能都是为了可读性而设立的,不是为了一次打字不纠结设立的。写代码的时候为了可读性而改已写好的部分是很经常的事情。退一步讲就算我写了单行 block,我发现此处多行可读性更强,那我就回头改为多行。这就跟回过头去对齐等号,加注释等等行为是完全一样的。

    我不认为“有更多选择”就带来“纠结”。抛开语法层面,本身代码逻辑,一种逻辑也有很多种可能的形式。那这一点我们为什么不纠结呢?

    然后就是可读性问题了。如果你习惯 C,那么 C 和 C++ 的很多发展本身也都是在提高可读性。举个简单的例子,上学的时候我和小伙伴写 C,包括老师,我们都是写 while(1) 来做死循环,大家都看得懂,但是按现在眼光都会用 true 代替 1。

    关于最后一点 c like 的问题,这世界上编程语言可以说五花八门海了去了,见得多了,每种风格都有它的好处。这一点个人认为不仅不是障碍,而且是必经之路。

  • 还是进程隔离好,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?写错了?