终端我用的 MobaXterm，复制粘贴，ctrl+shift+C / V，其他相关需要配置下。

比如直接进 WSL 并启动 ZSH+ 工作区，和指定公钥位置。

rails s 和 rake 任务启动会比较慢。

ubuntu 下载慢，改成国内源会好点。

嗯，主要还有一点原因比较重要，忘了写了。

是作为一个从 IE6 一路 hack 过来的伪前端，SJR 我一直用的不是太顺畅。SJR 把很多东西划分的太碎了，控制起来太费劲，需要记忆和查找，修改后容易相互影响。Stimulus 虽然把 js 作用域分开了，但 CSS 还是没有解决（因为它诞生的目的也不是为了解决 CSS 的问题），而且多了 SJR。

这样 JS，HTML，CSS，SJR，就分别散落在各个角落，支离破碎的感觉，很糟糕。

而组件化的颗粒度是我想要的。把 CSS JS HTML 封装到一个组件（甚至文件）里，而组件之间样式、行为互不干扰，修改微调起来相当方便，安心。

了解，我也是一直想把 Stimulus+Turbolinks 用起来，但是一直也没有找到合适的使用场景，可能新闻站、博客、论坛这种会比较适合，但是除了个人练手，现在哪家公司也不会花人力重头写一个这样的应用。做活动页模板的话，通常也不需要后端或者全栈的参与，主要是前端在工作。做后台应用的话，就是复杂项目了，这本身也是 Rails 拿手的，然而复杂应用的前端，可能就要上 react 之流会合适点。

至于复杂，前端现在确实很恶心，但可能也没想象的那么复杂，可能只是 Rails 社区对前端研究不多，不太会组织资源。

用过一段时间，没有想象中的好，比较鸡肋。

简单应用，用不用 stimulus 区别不大，大不了把 turbolinks 去掉，省的调试起来麻烦，还要写模板标记。

复杂一点的，由于担心越做越复杂，估计都会考虑用 react 之流。

青云可以灵活调整带宽，并支持定时任务、弹性调整和 API 调整。建议了解一下。

哈 Surface Pro 肯定不行的，之前的老的 I7 Macbook Air 都慢的一塌糊涂。 这个方案主要还是给台式机用的。一会发下磁盘 IO 测试结果。

en，文中有说，观点就是 wsl 的性能其实并不是很重要，损耗一些完全可以接受，我更看重系统 GUI 本身以及丰富的 GUI 软件带来操作效率提升。

并且除了运行环境，其他一切都在 WIN 上，包括代码和数据库。所以真正考验 IO 的地方就是 WSL 的文件挂载。

另外我是有 960EVO 加持的，所以实际 IO 强过主流生产环境 ssd 云主机是没什么问题的。

毕竟好看才是第一生产力

pytorch winfows 版支持 GPU，tersorflow 不清楚，你可以试下

我的也是家庭版，下载专业工作站版 ISO，双击打开，直接升级。完成后默认激活状态。若是没有激活，淘宝有 30 块钱电话激活。

news

create_one

目前，似乎没有，还未求证。

一个 nginx 后面可以有 n 个网站，nginx 负责把域名转发到后端，静态文件转发到文件系统，动态的内容交给容器（puma、tomcat）自己管理，当然也可以转发给另外一个 nginx 或是 IIS、Apache。

牛逼！

虽然不好意思说，但其实 RTFM 也是 Ruby 越来越少的重要原因之一。

参考过，很有价值，不过最终评估后，打算折腾一下 react_on_rails + webpacker + antd

新项目准备直接用 rc1，大概率没开发完，直接升级 release

按理说应该没几日了

这是个做时间序列应用时经常会用到的 tips。

Time.at(Time.now.to_i / 3600 * 3600)

需要按多少秒分割，先除以它再乘以它就好了

冲进度的时候加一段可以，但是结束后要用团建之类的方式补回多巴胺，长期加班简直是摧毁团队。

不过话说自己在家做项目基本是 12127，中间穿插好 play time。长周期的思维连贯性被打断还是很恐怖的。

JIT 的解释有误

每周固定踢足球 1 次（9 人制对抗 4 节共 2 小时）。健身房办卡，虽然间歇性的，但是经常会集中上私教课。家里备可快速调节重量哑铃 + 卧推板，做哑铃深蹲卧推弓步蹲。

https://ruby-china.github.io/rails-guides/action_mailer_basics.html

看你说了那么多楼，基本 get 到了，本质就是在说你在 Linux 折腾的时间比较久，熟悉了，想把原先的操作或 DIY 的习惯/经验，原封不动搬到 Mac 上来，失败了。

我想说那基本是不可能的，因为即使都是类 unix，Mac 和 Linux 毕竟还是两个不同的东西，设计哲学上就不一样。就像安卓 vs IOS 一样，如果只用过其中一种，即使别人再吹另外一种，你看起来好像也不错，但是去深度尝试的话仍然各种不习惯，因为是会带着原先的思路去操作的。

对比开发语言，如果一个只学过 Java/PHP 且用过 n 年的人，让他来用 Ruby，看起来很美，可是为什么生态里面各种奇怪的东西，为什么要 balabala，连个解决方案都找不到，你看我原来的语言多好，（比如你吹你是最屌的元编程，但是连个变量的变量都没有），其实本质上就是你习惯了原来的系统的设计哲学 + tips 合集而已。但是如果用过多种平台/多种语言工作的人一般不会觉得有什么问题。

另外由于用了好多年，所以各种解决方案都积累起来了，所以即使有些解决方案都是蹩脚的，但是踩过坑了熟练了，也就不觉得有什么不妥了。

所以要切换平台，基本上还是评估切换成本，然后对比切换前后总体收益是正还是负，切换后总会各种不爽，但是总体正收益的话，还是可以考虑的。比如 Ubuntu 再好，对我而言把桌面或服务器都切换过去，收益是负的。而桌面环境的话，非 IT 专业的各种软件还是 Windows 更丰富，我能列出一堆各种好用的大小软件。@huacnlee 所说的 Mac 上的 Office 能比 Windows 好用，肯定是不对的，微软在桌面办公积累那么了多年，比如 Excel 中使用 VBA，或 Excel 和 Access 的结合，Mac 都是没法比的。

而大部分时候，切换平台最重要的原因，只是因为我们最需要的那个功能/软件，在别的平台无可替代而已

看透就好。不过 APP 还是原生吧，创业还是不折腾为主。

补充一下： 低分屏下 Mac 表现不如 Win，但是胜过 Linux。Retina 屏 Mac 基本就是完爆了（含外接 4K 屏）。用久了 Mac Retina 屏回头去看 Linux GUI 觉得眼要瞎。(不过新 Air 的屏没了解过，无法评价)

另外性能方面 Pro 要远超 Air。转 Mac 最大不适应是习惯系统和快捷键。

习惯之后你会发现 Mac vs Linux 约等于 艺术流 vs 工业风的意思。

现在可以登陆了，到你社区反馈吧。

颜色一个是灰度问题，另一个色彩太不和谐。 登录不上吧。

passenger_env_var RUBYOPT "--jit";

O 了。

效果上，预热时间有点长，多个进程貌似是单独预热的，预热期 CPU 占用比较高。绝对速度还没有测。

期待你的结论。

已搞定

环境变量添加

export RUBYOPT="--jit"

后

在 nginx 里配置

passenger_load_shell_envvars on;

祝大家猪年涨工资！

估计是这两个字的问题