::File.expand_path(ret) 这段代码前面有个空格我不是很理解是什么意思
遇到看不懂的 Ruby 语法可以这样查:
Ruby Core Reference
,点击这个链接New to Ruby? You may find these links helpful: syntax, control expressions, assignment, methods, modules + classes, and operator precedence.
里面的 modules + classes
链接到的页面就有你想要的答案。
rex fileutils
find_full_path
, 可以找到这个方法的文档。如果是我遇到一个陌生的项目的方法,应该就会这样去找它的 API 文档,然后就能理解是什么意思了。
Just to be clear: 我相信大家说的“不折腾”可以解释为:时间是宝贵的,花时间维护系统 / 解决系统问题,没有产出,不值得。那么我愿意折腾系统,有着同样的原因:时间是宝贵的。我想通过提升效率来降低时间损耗。
至于说折腾投入的时间,和折腾之后提升效率节省的时间,哪个更多?我自己只能承认没有仔细算过这笔帐,甚至,我根本不知道如何算得出来。但我不相信支持“不折腾”的各位有计算过。目前我只能认为:双方都拿不出有说服力的证据,suspend judgement。
系统维护这点我确实没有太考虑。可能是因为用了太久的滚动更新 Linux 发行版,习惯了每天升级一次。现在想想,这种时间如果能节省下来一些,但又能及时用上较新的生产力工具,会好些。前阵子我也在探寻有没有能同时满足这两条需求的 Linux 发行版。Fedora 可能是个不错的选择。
是的。用休眠到内存 / 硬盘替代关机可以节省开关机 / 开关应用的时间。但我不清楚现在 Linux / Windows 在这方面做得如何了。我接下来会尝试一下在自己的主力工作笔记本上能否做到这一点,看看能把 uptime 累计到多久 (如果我不需要重启切换到 Windows 去玩游戏的话)。
3.1 可以虚拟化 / 租用机器体验 Linux 这个事,连同前面 #10 提到的“测试一下 Safari 的兼容性”的事情,让我觉得:Linux 在虚拟化方面有更好的支持,才给了用户这样的机会:不需要买与其捆绑销售的硬件。以前我专职做前端开发的时候,需要测试 IE6 的年代,也可以直接用虚拟机来跑起 Windows XP。前阵子我尝试在虚拟机里运行 macOS,困难重重,最终放弃(也许是我自己的问题,未来会再试)。那么我们是应该功利性地,因为 Apple 的不开放的策略去买 Mac,还是应该支持给用户留有自由选择机会,对虚拟化支持更好的 Linux / Windows?
3.2 拿 Linux 作为日常常用的系统来熟悉 / 练习,相比于:有需求的时候才访问一个远程的 / 虚拟化的环境,而这个系统也同样需要管理 / 配置,与原生系统间同步数据。虽然说能用,但也带来了额外的维护成本。
ss -tpln
,非常好记。4.1 我很想听一些具体的例子来支撑这样的观点。比如说,Sketch 是个优秀的 UI 设计软件。前端开发如果能直接打开 Sketch 文档,和设计师合作时可以直接从中读取 UI 尺寸(甚至直接生成 CSS)。如果 Sketch 的诞生是因为 macOS 的 GUI 开发平台有优势,那么我会同意:这是个 macOS 的加分项。
4.2 我工作中用到的软件大多数都是跨平台软件。我不知道它们能否算作是“Linux 软件”。至于说 Linux 独有的软件 / 功能,我尝试列出几个具体的例子来:
macOS iOS 的概念是你好好专注自己本行的工作,好好赚钱,操作系统、软件的事情交给专业商业公司,你付钱就好了。
Funny you should say that.
作为程序员,我的本行的工作是设计并实现软件给人使用。软件的设计就包括有 UI 的部分,软件的 API 也可以认为是另一种形式的 UI —— 只有程序员才会用的 UI。所以我的职业刚好需要我做出更好用的 UI,满足用户的需求。虽然我不是做桌面软件开发的,但 UI 设计的价值与原则是通用的:帮新用户成长为熟练用户,降低用户的认知负荷,设法为用户节省时间,诸如此类。
退一步讲,即使我的工作与软件设计无关,那么作为用户,我也可以发表评论。就像撰写电影评论的人,可能他们自己也没有拍过电影,但这不妨碍他们用影评来表达观点,影响舆论。
#28 #31 我在博客里已经写明了:我在 Linux / Windows 系统上已经把 Alt 和 WinKey 互换了位置。因为我用 WinKey 远多于 Alt。这是我使用 Mac 学到的改进。
但我在 macOS 上,如果要把 Fn 和 Control 键互换功能,用 macOS 自带的系统设置是做不到的 (可以把 Fn 映射成 Control,但不能把 Control 映射成 Fn)。只能求助于 Karabiner。话说回来,因为 Karabiner 只要用 homebrew 的一行命令就可以完成安装,我不会觉得安装这个第三方软件比直接使用系统支持的软件更“费事”。换句话说,我可以接受这一点“折腾”的成本。这点我只觉得是个不够好的默认设置,但既然用户还可以通过第三方软件来配置解决,那么也还可以接受。
我对 MacBook 键盘的最大的不满在于缺少独立的导航键(Home / PgUp / Delete,尤其是 Delete)。具体的理由我已经在第二篇 - 硬件篇里有解释。
这个事,我觉得你直接去 Ubuntu 的各种社区提问,才会有答案。在这个以 macOS 为主题的帖子里很难有人回答的。
有几楼说到快捷键“适应了就好了”。我不能同意这种观点。
举这么个例子:用桌面浏览器访问京东 / 淘宝,进入登录页面,页面上首先显示的不是帐号密码的输入框,而是手机客户端扫码登陆的二维码。每次登陆时,都要多付出一次点击,才能用帐号密码登陆。我已经适应了这个设计,但我依然觉得这个设计不好,因为它让我浪费了时间。
也许我应该用 user script 彻底解决这个问题。而不是适应它。
如果我自己想要反驳一个观点,我会尽量避免去揣测这个观点的作者的心态。因为我完全拿不出证据来证明对方的心态确实如此,只能承认这是个猜测。而且这在逻辑谬误中属于 ad hominem。
我也不是 Linux 系统开发者,但我的电脑上的软硬件是我完成自己日常工作的工具,如果这些工具能帮我提升效率,节省时间,那么这对我当然是有益的。"不折腾"这个观点我经常看到有提及,但我不太清楚这里是指减少初始设置的时间成本,还是减少后续维护的成本,还是两者兼有?我想要能够正确地理解这个观点的意思,再展开讨论。
Again,虽然我不是 Linux / macOS 系统开发者,但我作为用户,总可以按照我的价值标准(设计的一致性,易用性,完成任务的效率等等)去批评系统的设计。类似地,我不是技术书籍的作者,但我可以写书评,来表达我在读者的视角,对书的内容、写作方法、易读性等方面的意见。把自己的意见传达到社区,让能达成共识的读者共同抵制劣质的书籍作品,让出版业界(但愿)能提升未来出版物的质量。
我可以理解你做出的“精力应该放在自己工作的领域”选择。但我自己也愿意浪费这个时间去写对软件的批评。而你所做的选择并不能用来反驳我的观点。
@046569 @nouse 多谢。我应该会在未来慢慢体验这些。
删除文件的快捷键 command + delete
我在顶部菜单里看了一下,才发现其实是有提示的。但之前我只在右键菜单里观看 / 使用这个功能,而 Finder 的右键菜单里就没有显示命令的快捷键。作为对比,Chrome / VS Code 的右键菜单,都会把功能的快捷键显示出来。
编辑补充:之前我在顶部菜单 Help -> macOS Help 里找到了 macOS User Guide,想看看一些 macOS 上的入门基础知识,但这个 macOS User Guide 的窗口没法用 Command + Tab
切换过去。阅读体验极差。考虑到这个问题并不影响日常使用,而且猜测大多数用户应该也没有看帮助的习惯,我也就没有写进博客里。但我自己也就没再花时间去读这个 Guide(而且我也不知道这个 Guide 里是否有上面说的删除文件的 hotkey)。
前阵子听说 Homebrew 的 Linux support 好像是更成熟了,可以在没有 root 权限的环境下使用这个包管理器安装 Ruby 试试:https://docs.brew.sh/Linuxbrew
再就是用 static link ruby
搜索了一下,找到这个项目:https://github.com/phusion/traveling-ruby 但是我还没仔细看文档。
上面两个方案我都是临时搜出来的,自己没有试过,不知道是否可靠。但愿有用。
额外地,用 @ 人的点名提问的方式,是论坛规则里的《提问的智慧》一文所不提倡的:
呃,看来我在文章里写得不够清楚:
直接说出来太羞耻了(
可以从我的 RubyChina profile 找到我的 Github,然后再找 dotfiles 仓库,这个仓库的历史基本就是我的工作时间。
我很想就一些具体的观点深入讨论下去,这样我才有可能从自己 Linux 用得太久的偏见里爬出来,从 Mac 上学到新的知识(除了第一篇,后面三篇里零散地都已经有一点)来改善我现有的工作习惯。
比如说,你认为“linux 的 gui 就没一个能打的”。那么,具体要如何才能评价一个 GUI 是否是“能打的”?Linux 的各个 GUI 在这个评价标准里,在完成哪些操作的时候不如 macOS?我很想更多地了解,越具体越好。
比如说切换窗口 / 桌面的动画效果,在 macOS 上我实在没找到在哪关掉。在我看来,关掉不必要的动画效果,可以更省电和省时间,这是对我有益的。但我也不会用“能打”这种流行语来概括,因为省电 / 省时间应该是更容易被其他人认同的价值。用“能打”反而让我的表达更模糊了。
额外地,假如我想要反驳一个人的观点,我肯定会避免使用“90% 的评论”这样的说法。因为这会把具体划分 90% / 10% 的责任落在我自己身上,给我自己增加驳斥对方观点的负担。如果不说明哪些观点属于 90%,那么就等于没有给我自己的观点找到论据。那么我的观点就没有说服力。
有一个考量是日志和监控。
我在负责的项目的现行做法是在应用代码(语言是 Python)里写一个专门的 WSGI 中间件,这个中间件负责把请求耗时和请求的一些元信息(URL path,HTTP method 等)发送到储存服务(目前在用 InfluxDB)。
如果遵守了 REST 设计规范,那么 HTTP method 加上 URL Path(不包括 query string 部分)就足够表达这个请求落在哪个接口。在展示监控数据的 dashboard 上可以按照这些元信息来筛选数据。如果要自己发明约定规则,那么收集 + 储存 + 展示数据的服务都需要对这个约定 aware 才行。换句话说,这些服务都要对"是否包含 id 字段"做区别对待。虽然这个问题自己写代码总能解决,但遵循了 REST 约定就可以享受现成的方案,节省开发者的时间。
如果我想把上述的监控数据收集方案改成用日志收集 agent 来转发负载均衡的访问日志,从而少写代码,进而移植到别的应用 / 服务(很可能不是用同样的编程语言编写的)上去,那么这时遵守一个更流行的规范就能节省更多开发时间。
在 YouTube 上有的视频已经有自动地语音识别生成的英文字幕了。点播放界面右下角的齿轮按钮 -> Subtitles/CC 可以看到。
目前一个常用的理由是作为 Docker Image 的 base image。可以有效减小镜像的体积。
比如 Nginx 的 Docker 镜像,以 debian:stretch-slim
为 base 的 1.14
版本要 109 MB. 而 1.14-alpine
只有 16MB。
体积更小,那么下载速度更快,需要去清理硬盘上的旧镜像的频率也更低。
这篇文章下面的评论里就有不少反对这篇文章的声音。我也尝试着批判一下试试:
另一方面则是因为这样极端的饮食模式很难长期坚持
这里我不太清楚作者所说的"极端"是指什么。从旧石器时代饮食 (Paleo Diet) 的思路出发:人类在旧石器时代,没有保存食物的技术,没有磨制石器可以处理粮食。只有应季鲜果才是糖分来源。一年中的大多数时间都要猎取动物为食。所以这种饮食方案其实更符合人类的消化能力。
关键的一点在于,我们的身体,并不喜欢这种“饥饿”状态,它不希望葡萄糖被耗光。
这点我不清楚是否有理论支持。
人体有能力把其他物质 (储存的脂肪,蛋白质) 按需转化成葡萄糖。这一过程称作糖异生 (Gluconeogenesis).
天天吃得过于油腻以致参与者们胃口不佳、食欲不振、越吃越少
我个人吃得油腻照样能吃得下去。我的食欲确实比以前更差了些,但并不是油腻所致,而是瘦蛋白 (Leptin) 的作用。而且低糖摄入 -> 减少了因为糖分分泌的多巴胺 -> 减少了糖分上瘾。这也是食欲下降的原理之一。
这一说法的理论基础是,当血液中的酮体浓度升高后,神经中枢会抑制食欲。道理好像讲得通,但是大部分的研究结果都显示,这一功效是子虚乌有的。
我在研究生酮饮食的时候,从来没有听说有"酮体抑制食欲"这样的理论。这里作者犯的错误是稻草人谬误。
机体组织缺少了碳水化合物时,生理功能会发生障碍。
Again, 本着 rule of clarity 的原则,我看不懂这里作者说的是什么。没法评论。作为科普文章,不把话说清楚,让人无法验证真伪,很失望。
当进行生酮饮食减肥,杜绝了绝大部分碳水化合物时,血糖水平会下降,容易出现头晕、眼前发黑、出冷汗、乏力等“低血糖反应”。低血糖情况严重时甚至会使脑细胞受损,造成不可逆的脑损伤。
这些低血糖反应在这个网站里都有描述,并且介绍了应对措施:https://www.dietdoctor.com/low-carb/side-effects 简单来说,有可能是因为身体适应生酮饮食,有一定的适应期; 另一种可能是缺乏盐分 (低糖 -> 低胰岛素 -> 低盐分存留). 像我这种平时吃饭就不清淡的,基本没有遇到什么不适。
至于说脑细胞受损 / 脑损伤,我还是想知道"为什么会这样". 作者在文章结尾列出了不少参考文献,但并没有指出哪一个参考文献支持了这个观点。我不是很想替作者去一个个文章翻阅 (有些文章已经无法在网上浏览了)
Again, 有需要葡萄糖的地方,可以通过糖异生来满足需求。
当我们抗拒碳水化合物的时候,由于食物种类单一,脂肪以外的一些营养物质,比如部分维生素、纤维素、矿物质等的摄入会大大降低
少吃碳水化合物,依然可以吃大部分蔬菜 / 少数低糖水果。蔬菜里的维生素 / 纤维素 / 矿物质足够了。
体内蓄积大量酮体的时候,身体还有可能陷入酮血症或酮尿症。此时血液有酸化现象,轻者会出现恶心、呕吐等症状,重者甚至会发生脱水与休克,危及生命。
这里说的血液酸化危及生命的病症,叫做酮酸中毒 (Ketoacidosis). 如果是Ⅰ型糖尿病患者,会因为无法分泌胰岛素,无法抑制脂肪分解,进入这种状态。而健康人 (包括Ⅱ型糖尿病患者), 只要分泌很少的胰岛素,就可以避免进入酮酸中毒。
至于说酮血症 / 酮尿症,我目前能找到的描述,都只是说酮体在血液 / 尿液里含量升高。但都没说对会人体造成危害。
最后我还是稍微花点时间,仔细看看这篇文章引用的文献到底是怎么说的:
全文链接:https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5579615/
直接看 Conclusion: Atkins Diet (先严格生酮,后稍微放宽糖分摄入) 的短期与长期减肥证据明显,其他饮食方案证据不太明显。可以说是在支持以生酮饮食减肥。
链接:https://bjsm.bmj.com/content/51/2/133.short 点页面右上角的 PDF 图标可以查看全文。
直接看全文最后的 "How might it impact on clinical practice in the future?" (这对未来的临床实践有何影响) 一节:
A growing understanding that obesity/hypertension/T2DM/nonalcoholic fatty liver disease/atherogenic dyslipidemia and the metabolic syndrome may all be substantially influenced by a single over-riding environmental factor—a high carbohydrate diet, acting on a single metabolic state, insulin resistance—will revolutionise the medical and dietary management of these conditions over the next decade. From our analysis, the LCHF eating plan should become the default medical management approach for all these conditions.
为了降低各位读者的翻译压力,减少可能的翻译错误,我亲自给大家翻译:
对于肥胖 / 高血压 / Ⅱ型糖尿病 / 非酒精引起的脂肪肝 / 血脂异常导致动脉粥样硬化这些疾病,以及相应的代谢病症,现在我们越发地认识到:它们的决定性诱因可能都是同一个后天要素,那就是:高碳水化合物饮食,使病人进入胰岛素抵抗这种同样的代谢状况。这一认知,将在下个十年,对这些病症的医疗与饮食管理思路发生革命。根据我们的研究分析,LCHF(低碳水化合物 - 高脂肪) 饮食方案,应该成为应对这些病症的默认医疗方案。
也就是说,这篇研究报告认为低糖饮食应该成为下个十年的革命性的实践。而果壳的文章引用这篇文章来说明生酮饮食的危害和不确定性。
到这里我已经不想再分析下去了。因为果壳文章的作者似乎并没有花和我一样多的时间,来认真看看至少其中一篇参考文献是否支持了他自己的观点。我想各位读者也能做出自己的判断了吧。
顺便,最后那篇研究报告的第一作者 Tim Noakes, 在 YouTube 上可以搜到不少他的演讲 / 访谈,宣传低糖饮食的好处。好奇生酮饮食的同学不妨直接听听专家的意见,而不是相信为了流量而拼凑文章的"科普媒体".
push image 没有那么慢。因为我们用的私有 Docker Registry 和 CI / 生产环境服务器都在同一个内网网络 (某公有云平台), 再加上合适的 Docker 分层缓存,如果没有依赖更新,每次 push 的量也就只有仓库里的几 MB 的代码量。16 秒的时间已经包含 push 在内了。
不过如果你真的要计量精确的部署时间,还得把 GitLab CI Job 的运行前的延迟加上。Job 在触发运行之后,会有几秒钟的时间停在"job 正在等待被某个 runner 认领执行"的状态。
rollback 我们没有专门的方案。如果需要部署到旧版本,可以 SSH 到 Docker Swarm Manager 上手动执行 docker service rollback
. 也可以直接在 GitLab 的界面上找一个旧版本,再点一次部署。因为应用服务器上的旧版本镜像还在,不需要重新下载,这样部署的时间会更短一些。而且这样做,不需要担心引入了回滚操作而制造更多的语义。比如:不用担心"回滚的回滚"应该是什么意义。就不会造成误解 / 记错。
我们用的 CI 工具是 GitLab 和它的 CI, 部署用的是 Docker Swarm.
选用 GitLab CI 的想法是和 GitLab 紧密整合:把最终部署的步骤写成一个 CI job, 在项目的 Pipeline 界面手动触发这个 job 就可以部署。不用开发者学用一个新的软件界面。
部署耗时:目前我们放宽了 CI 的流程限制,合并进主干的代码不用等测试跑通,就会先构建 Docker Image. 构建好了之后就可以部署。
docker service update
. 因为要滚动更新,还要下载镜像,这个时间稍微长一点。最近一次要 66 秒。未来应该还有提升空间。Windows XP / 2003 都是不被支持的 OS 了,不再收到安全补丁更新,新软件支持越来越少。有什么理由一定要用么。
如果可以不用,还是推荐升级到 Windows 10.
看到有不少回复说运动减肥的事。Well, 生酮饮食和运动并不冲突。可以两者并行的。
而且再回到主贴的"需求分析"一节:我想要用节省时间的,执行简单的办法。运动这件事对我来说,既没有这方面的爱好,又太花时间。所以我没有选择运动。
我微信只在工作时才用。平时基本不用。实在想要私聊,给我发 Email 吧。地址在论坛的个人资料里有。或者如果你用 IRC 的话,我会在 Freenode 的 ##devcn
频道常驻。
话说回来,如果你真的想要开始尝试这种饮食,我没法给出负责任的意见。最好还是自己去研究。
是的,会低血糖。但低血糖这件事本身不是问题。
如果你在担心低血糖等于身体缺少能量来源,会导致头晕,无力等症状,这会在身体转用脂肪供能之后自然适应。适应期可能有长有短。
但生酮饮食由于低糖 -> 胰岛素分泌降低 -> 身体存留的盐分减少,可能会由这个原因导致头晕 / 无力 / 等一系列副作用。这个页面有集中介绍生酮饮食的各种副作用:https://www.dietdoctor.com/low-carb/side-effects 其中大多数副作用的原因都是缺少盐分和水分。这样意味着重盐的饮食习惯对生酮饮食是有帮助的(是的,生酮饮食可以多油多盐,照样减肥)。
如果你需要运动,担心身体缺少糖元储备而影响运动能力,这方面我完全没有去调查过。但如果我现在要开始考虑这个问题,会从 /r/ketogains 的 wiki 开始看起:https://www.reddit.com/r/ketogains/wiki/index
简单来说,是的。
具体来说,还要避免一些制作过程加入的淀粉:比如油炸 / 丸子食品都要用淀粉。
但生酮饮食是个量变而非质变的事儿,不用担心“吃了两个带皮的饺子就要用 N 天严格无糖饮食补回来”。只要尽量降低糖分摄入就好。
因为西红柿含糖量低。
这个饮食背后的理论与传统的食物分类无关,只看糖分多少。含糖低的水果也可以吃。
再就糖分的影响更多的是量变而非质变。所以稍微多吃了一点也没事。
是的。能自己做饭那么确实会容易很多。但我自己是不会做饭的。
我不清楚你所说的“真正的 Keto”是怎样的标准。但 /r/keto 的 FAQ 里也说了:可以放宽到每天 100g 糖分摄入,只不过减脂的速度会慢一些。所以在外吃饭吃到调味加的糖,也还可以接受。我打算等到自己体重降到理想水平时,就把糖分摄入提高到这个水平,用来吃水果,偶尔吃甜食。
至于吃肉比较昂贵的问题,我的体验是开始 Keto 之后食欲会下降,可以每天减少一份正餐,能挽回一点吃饭成本。
猜测 PostgreSQL 的流行程度增长,和 Heroku 有很大的关系。
如果没记错的话,Heroku 是第一个把部署简单的 PaaS 做大做好的公司。而这个平台最先支持的编程语言是 Ruby,最先提供的数据库服务就是 PostgreSQL。
我记得 bash 有一种技巧可以记住程序的路径
有的,看这里:http://mywiki.wooledge.org/BashFAQ/081
你的问题的原因应该是:因为 alias irb=pry
,那么当 irb
是 bash 命令的第一个 word 时,这个 alias 就会生效,运行起来的是 pry
。而运行 env irb
这个命令时,alias 可能是不生效的。
官方文档大概都会有解释。
用 Google 搜 ruby language keyword
搜出来的第一个结果刚好是官方文档的 keywords 页面,点进去可以找到 and
。
何以见得?
假如还不能开始使用容器化方案(如 Docker)的话,至少也考虑用配置管理(如 Ansible)。而且还能搜到现成的方案:https://github.com/j-mcnally/ansible-rails