整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
前记得有跟大家介绍过一款号称终端神器的一款软件 MobaXterm ，为什么会号称终端神器呢，在我看来是内置了一个 Cygwin，支持很多基本的常用的 Linux 命令，比如 awk，cat，grep，find，tar，history等。
就算某些命令提示Command Not Found，后期也是可以通过 apt-get 来管理（安装、卸载）这些所需的命令，而且命令也可以在类Linux系统上运行，不仅省去了命令学习的成本，而且对于初学者来说，可以上手即用，不需要手动搭建虚拟机也不需要安装 WSL 。
昨天给大家说了 MobaXterm 怎么新建各类终端会话，今天再说说如何将已经存在的会话分类组别。
文件太多的时候，为了便于管理我们会将文件放入文件夹来管理，当然 MobaXterm 终端会话比较多的时候，也可以使用文件夹来分组管理。
右击 User Session 后会弹出菜单选项，
New session：新建一个会话
New folder：新建一个文件夹
Clear saved sessions：清空所有已保存的会话
Create a desktop shortcut：创建一个桌面快捷方式
Export all sessions to file：导出所有会话到文件
Generate HTML web page：生成HTML网页
Generate HTML web page：生成HTML网页
点击该选项后会生成一个HTML页面，页面内容就是下面这样的，单击某个会话可立即打开对应的会话，但电脑必须有安装 MobaXterm才可以。
那么今天就先写到这儿，有疑问记得在评论区留言、后台私信留言
MobaXterm 往期推荐阅读：
文/奇趣异阁（始发于公众号）
一个致力于日更365天的利他主义者，Windows效率软件重度使用者，也是一个懒人，有关于软件效率提升的问题都欢迎与我链接，今天是日更的第160天，作于2022/7/23。
者 | Noah Gibbs
译者 | 弯月，责编 | 屠敏
头图 | CSDN 下载自东方 IC
出品 | CSDN（ID：CSDNnews）
以下为译文：
什么场合下不适合选择Rails？
首先，我介绍一些很明显不应该使用Rails的场合，然后再探讨一些值得从技术角度去考虑的情况。
首先，最重要的是团队熟悉程度。如果你的团队根本不了解Rails，而且对Rails的学习也不是特别感兴趣，那么就不适合选择Rails。这种情况应该很明显，但仍然应该是第一考虑要素。
其次，当你知道其他框架更合适的时候。有时候你会特别关注一些方面。如果你需要使用Java语言的机器学习库，并且由于某种原因你不想使用JRuby，那么就不应该选择Rails。如果你需要编写WordPress插件，则会选用PHP。有些特定的兼容性问题往往比其他所有问题都重要。
如果能够发挥Rails的优点，同时缺点没有太大影响，则可以选用Rails。因此，下面我们来讨论优Rails的缺点。
另外，通常Rails只能用作HTTP服务器，因此某些任务不适合Rails。
不适合使用Rails的情况包括：
非常小且不会增长的任务。如果某个服务的功能非常有限，那么使用Rails就有点大材小用。如果你不需要数据库，那么就没有必要建立数据库，对不对？如果只是一个流量非常低、不需要缓冲的中间服务器，那么使用Rails就得不偿失。
但是，你需要谨慎处理不断增长的任务，不断扩大小型服务器的规模会带来很多麻烦。如果你的服务需要通过Web浏览器向用户提供HTTP页面，那么必须考虑将来可能需要添加的功能。仅靠最简单的解决方案远无法应对这种情况。
简单的API服务器。Rails并不擅长提供支持JSON的API服务器。Rails的许多HTTP安全性都无用武之地（例如SQL注入防护、XSS防护等）。虽然对于某些数据库而言，ActiveRecord是不错的选择，但当你构建需要与浏览器对话的HTML网站时，Rails才能发挥最大优势。一般，在仅供机器使用的小项目中，Rails的用处不大。
与之类似，如果你需要在浏览器中渲染HTML，而Rails只负责提供JSON数据。这时，许多Rails的安全功能和便捷功能就形同摆设了，但ActiveRecord、ActiveJob、ActionMailer等内部库仍然不容小觑。但如果你不在服务器上渲染HTML，而且非常确定以后绝对不会，那么就不要纠结Rails了。
Rails是为小型团队和中等规模的代码库设计的。超大型团队（许多程序员）和超大型代码库（大量的控制器、模型、代码行数）会拖垮标准的Rails应用结构。
在Ruby中，你可以编写带有非局部副作用的代码。不论是猴子补丁，还是写入数据库，或者是在运行时创建新的类型，对于一个200人的团队来说，如果你无法信任每个人，那么就不应该选用Ruby。有时方法太多，反而会让人头疼。有一些很好的工具可以方便在大规模团队中使用Ruby，但即使如此，也很容易遇到异常和困难。这并不是Ruby擅长的领域。
大多数时候，你可以将一个大型项目分割成多个较小的项目。如果一个Rails应用过大，那么通常可以将其分割成多个应用，或者一个较薄的应用加上多个后台服务，或者一个应用加上一个微服务，等等。不论哪种方式，总有办法将其分割成小部分。Ruby非常鼓励这种做法，而我也非常赞同。
有些结构虽然不太像Rails的风格，但能很好地扩展规模。Avdi Grimm（已退休）提出的Objects on Rails就是这方面的一次尝试，还有Hexagonalarchitecture for Rails也是，它与更古老、更通用的N-tier architecture有很多共通的地方。
但有时采用其他框架更好。一个明显的选择就是Hanami，在创建微型应用程序时它不像Rails那么快捷，但在大型团队中，它的扩展性更好。
个人而言，我还是会从Rails下手。如果只想快速开发，然后看看市场反响，那么没有任何框架的生产力可以与Rails媲美。等到市场成功，而且可以适当降低开发速度时，再用更坚实的框架重写就好。
另一个需要考虑的是性能问题。如果你要重写一个普通网站，那么实际上性能并不是问题，Rails在这种规模上依然能够良好地扩展。但如果面对几百倍大的网站（如B2C网站），那么有可能你的服务器费用会超过人工费用。住这种情况下，可以考虑降低工程师的工作效率，开发效率更高的网站，以节省服务器费用。可以查看一下你的应用服务器的账单，只看看运行Rails的应用服务器就好。然后对比一下Web工程师（即负责编写Rails应用的人）的工资。一般而言，工程师的工资要远远大于服务器的费用，所以应该使用廉价的服务器时间来换取昂贵的工程时间。但在某个点上，天平会倾斜，此时就应该考虑提高工程师的工资，以此来降低服务器开销。
在讨论Rails的假设是否正确之前，我们先看看这些假设是什么。
Rails有一些简单的假设：它假设你编写的是在服务器上渲染HTML的交互应用。它假设安全性非常重要（Rails为了安全性放弃了很多），而大多数情况下你不会自己构建安全系统。它假设你有一个精英小团队来做原型的工作，或者你有一个中型团队，但有完善的指南。
Rails还假设，你愿意用技术债务来换取更快的开发速度。换句话说，Rails的目标是快速构建应用程序。当技术执行力不是首要考虑的风险时，这种做法很合理。例如：如果你有一个小型的创业公司，你很确定你能构建网站，但人们并不一定会买你的产品，那么你最大的风险就是市场风险。此时Rais应当是首选。你需要迅速构建。因为就算你能做出完美的产品，也可能因为非技术原因（如“人们不愿意买”）而放弃。
鉴于“开发速度优于技术债务”的信条，Rails假设你会使用大量的gems，而且只要能加快开发速度，添加依赖也不是问题。
Rails假设你不在乎水平扩展应用服务器（即添加更多的应用服务器）。如果你能做到这一点，它就能很好地扩展。Rails假设CPU很便宜（一般来说这是实话）。相应地，Rails还假设数据库通常是最严重的性能瓶颈（一般对于Web应用程序来说，这是实情）。
Rails还假设你的应用程序需要进行一些计算或数据传输。它假设可以使用CPU，因为无论如何你都要用CPU做一些计算。
尽管Rails擅长做很多事情，但有一件事是它不擅长的：垫片（shim）。
所谓“垫片”指的是自身计算量非常少，功能只是将几个其他后台服务的结果集成到一起并转发的服务器。例如一个服务器，查询两个JSON服务，并将结果简单地字符串连接。它的计算量非常小，但需要处理许多事件。
这里的关键词是“事件”。
Node.js支持一种特殊的应用程序架构，叫做“Eventd”（事件）编程。它仅使用非常少的资源就可以支持上千甚至百万级别的同时连接。它可以同时实现高吞吐量和低延迟。如果用在合适的地方，它的性能无人企及。
Rails完全不如Eventd编程。其实没有哪个框架能比。Ruby也有Eventd编程框架（如EventMachine、Async），但Rails完全不同。
既然Eventd这么好，为什么不在所有场合下都使用呢？因为它并不适合一切场合。我特别想强调的是每个请求的计算量，如果每个请求都执行很多计算，Eventd服务器就会挂掉。对于一台能处理百万连接的服务器，如果每个连接需要几百毫秒的CPU时间，那么就大事不妙了，因为请求量太大，延迟也会非常糟糕。
换句话说，Rails和Node.js是适用于不同项目的不同工具。如果你认为“这个项目使用Rails或者Node都可以”，那么我建议你仔细想想你的项目（以及框架），直到找出明显的正确答案。这二者的用处完全不一样。
如果团队不想用或者不会用，那么Rails就是错误的选择。
如果很明显其他框架更好，或者某个需要兼容的库并不支持Rails，那么Rails就是错误的选择。
如果不在服务器上渲染HTML，特别是当项目非常小，并且不使用服务器时，那么Rails可能是错误的选择。
如果不做原型类的工作（最好是在小型、高竞争力的团队内做），那么Rails就是错误的选择。
如果开发团队或者应用代码太大，并且无法拆分项目时，那么Rails就是错误的选择。
如果项目需要Node.js的Eventd服务器或者EventMachine一类的功能，那么Rails就是错误的选择。
最后，如果你只想听关于这个话题的娱乐新闻，那么这篇文章就是错误的选择。
评论1：
我来根据我的经验说说为什么应该坚持使用Rails：
所有“轻量级Sinatra API（或者类似的API）”服务最后都会越来越像Rails应用。Rails给开发者提供了很多遍历，除非你自己开发一个轻量级API，否则都不会注意到这些。例如控制台、日志、数据库迁移、数据库连接池、rspec集成、i18n等。
没人喜欢自己写项目结构。代码放在哪里？是lib？core？还是app？你觉得ActiveRecord太臃肿而“无法扩展”，所以就自己编写了一个轻量级“数据映射器”模式？但不好意思没有人愿意花时间去学习。话虽如此，Rails项目还是有一些可以随便挑选的部分，只不过不符合大家的习惯。
大部分时候，开发者会假设数据库连接池是一件很自然的事情。系统管理员不想调试你的程序。在反反复复几个星期后你就会认识到，数据库连接池是Rails提供的。而仅仅在Sinatra应用中导入activerecord再建立连接，是没有数据库连接池的。
某天，某个负责生产环境维护的人忘记了rake任务的名字。在运行bundle exec rake时忘记了添加-T。默认的任务是rspec。结果把生产数据库删掉了。到时你就会明白，Rails会阻止类似的事情发生，而那些“轻量级API”不会。但是，这种教训显然还不够深刻，因为几年后类似的事情还会再发生一次。
评论2：
对我来说Rails不可或缺，你只需要15分钟就可以从零开始构建一个网站在Heroku上运行，顺便设置好SSL和域名。我特别懒，所以即使不用数据库我也会使用Rails。所以我甚至不知道能不能在没有数据库的情况下运行Rails。
说实话，即使是JSON API加上React前端的模式，我也会用Rails。因为实在太方便了。
评论3：
我还是会选用Rails。如果你想快速开发，然后看一看有没有人喜欢，那么没有任何框架能够比得上Rails。
我有5年的RoR经验，两年sprintboot/kotlin经验，1年的Django经验。一旦设置好工作流程后，生产力方面就不会有太大差别。痛点仅在设置初始项目，以及在库版本更新时随时保持更新。
django和spring boot缺乏的就是实体、控制器和视图的命令行生成器，以及快速设置流程。
Django和spring boot需要在设置上下点功夫。Django需要settings、应用程序数组、中间件定义等。一旦这些工作都做好了，编写实体、视图和路由都非常简单。
Springboot需要坚实的文件夹结构、应用程序属性文件，还需要仔细设置好数据库迁移和日志。所以并不是那么容易上手。但编写实体、控制器、服务、视图等还是很方便的。
原文：http://codefol.io/posts/when-should-you-not-use-rails/
本文为 CSDN 翻译，转载请注明来源出处。
场PUA和职场霸凌是大家近来常常谈论的话题。
它比996和007更隐晦，因为当中充斥着对人的操控：“为了让你成长”“你其实一文不值”等论调，都是对精神的一种摧毁和透支。
新片《助理》（The Assitant）恰好展示了在当代文化浸润下，接地气、也压抑的职场霸凌日常。
写实的职场环境，和其中体现出的对“人”本身的轻视，让很多人都能在其中找到共鸣。
职场小白的“社畜一日”
简（Jane），一个毕业不久的名校生，就读西北大学（Northwest University）的她成绩优异，梦想成为一名制片人。
阴差阳错，她进入一家业界有名的影视公司，成了身为娱乐大亨的老板最不起眼的初级助理。
这个职位可能会给她带来意想不到的机会，但现在看来，这种前景近乎奢望。
因为她的工作内容相当沉闷：
在黎明前赶到办公室，逐一打开同事们办公桌上的灯，煮好咖啡、在茶水间洗碗，换好复印机里的纸张，为同事们打印报告、预订午餐，抄写剧本、审核不明所以的表格，为老板和客户相应安排旅行和住宿，确保机酒都被安排妥帖，并且在办公室空无一人后离开。
没错，这是一个社畜小白的纽漂生活。
不可否认，相当多的厉害人物，在初出茅庐时都需从入门级做起。但简的职责之琐碎、界限之模糊，让人忍不住质疑，这些工作内容是否需要一个GPA3.8+的名校生来完成。
不过，简的职场生活也有刺激的时刻，那就是替老板来应付老板娘的电话。
怒气冲冲的老板娘质问老板为什么冻结信用卡，或是追问老板人在哪里时，简不想对电话那头的女人撒谎，只能“打太极”。
看上去在简的工作时间里，很难有自我提升的选项，因为最说得通的选择就是迎合老板的需求。
不过，她也捕捉到了一些隐秘的事。
一位年轻美丽的女孩从爱达荷州飞来，只有女服务员的经验，老板也让她先当助理，再入行。
在护送那名女孩去高级酒店的路上，女孩问简，大家刚开始做助理的时候是不是都住在这同一家酒店。
可怕的片刻沉默后，简说：“不是。”
另一名年轻女子来到办公室里拿走掉落的耳环，简默然看着她，二人不需要任何言语的交流。
简跌进了老板的黑暗秘密里。
性侵故事的“新视角”
这部电影的导演是基蒂·格林（Kitty Green），以拍摄纪录片见长。
基蒂·格林的《乌克兰不是妓院》剧照。她曾以此片获得威尼斯电影节提名。
格林称：“在拍这部电影之前，我看了很多关于这个话题的书，比如说，老板有了‘访客’之后，要把老板的沙发打扫干净。”
这是一部基于韦恩斯坦案细节的职场电影，它对性侵和沉默文化采取了很特别的视角：底层员工。
格林说，“媒体总把焦点放在这些男人身上，而不是围绕在他们周围的系统和让他们掌权的结构上。我想从不同的角度来看待它，不是从上往下看，而是从下往上看。”
在剧本准备阶段，格林采访了将近一百位非常入门级的职员，辗转相关公司去深入调查。
最后她发现，类似的职场故事总是一次又一次地出现，横跨全球：
“我不得不去拿咖啡，因为我是个女人。这很荒唐，真的让你怀疑自己的野心，让你怀疑自己是否能走到有那些权力的位置。让人觉得有点高不可攀。”
“我确实注意到，我的自信是如何被剥夺的。当人们不把你当回事的时候，确实会动摇你的自我感觉。”
简的扮演者茱莉亚·加纳（Julia Garner）说：“很多人，无论男女都是受害者，他们甚至没有意识到自己是受害者。”
加纳与导演格林在片场
全片没有任何一帧老板的正脸镜头。
从简与同事的对话、简从办公室捡到的耳环、发带以及简接到的上司老婆的电话等等，大家便对这位上司的行事作风一目了然。
但每个人都学会了，在糟糕事情发生的时候，目光移开，视而不见。
《名利场》评，“这是一部有力量的电影”，当主题变得近乎沉默，力量感却丝毫不减。
导演把成片给一个大制片人朋友看，制片人过了三周才回复，表示自己手下几名助理确实也情况相似，头一回感到，“真的很内疚”。
职场霸凌的摧残
即使现实中的老板不是韦恩斯坦这种性侵惯犯，那种近乎霸凌的责骂，也让不少观影者联想到了自己的职场困局。
片中去找HR试图投诉的简，贡献了关于职场谈话相当精妙的一段戏。
抱着对那位新助理境遇的疑惑与担忧，简找到了人力部门，和一名看似热情友好的男性HR沟通自己的疑虑：
对性侵真相心知肚明却选择视而不见的HR，说了如下这段话，为广大人力资源同伴们送上了非常好用的“职场控制模板”。
先制造危机感，转移女主角的注意力，让本来努力靠近真相或者捍卫自己理解的“正义”的简，突然惊慌地开始考虑自己最基本的“生存问题”，还能不能保住这份工作。
更加“高明”的做法，是把“性侵投诉”无声地扭曲成“女性之间的嫉妒”，把老板的恶习问题或者制度对老板的袒护，变成一句简单的：这是你自己的问题。你嫉妒人家。
职场对人的压迫，确实有比性侵更为隐蔽和常见的形式。
寻求帮助的无助局外人，不仅感受不到“帮助”，最后只能体会到被四面墙死死压住的恐惧——那是一种密不透风的孤独。
最令人感到讽刺的一幕是，简决定放弃投诉离开人力部门时，HR用男性特有的视角上下打量了简一番，风轻云淡说了句：“不要担心，你不是他的菜。”
被孤立的简回到办公室，衡量片刻后决定做回沉默的旁观者，可HR已经把她的行径向老板一五一十告知。
于是刚回到工位，简则接到老板盛怒之下的斥责电话，抛出那句职场名句“你还想不想要这份工作了”。
很难讲这段话算不算得上大家近来热议的“职场PUA”，但当中充满着一个上司对下级在“人”层面的贬低。
“你是那么渺小与可悲，哪里配挑战我高高在上的权威。”
被现实碾压的简识趣地决定给老板写一封道歉信，也是在此刻，简获得了片中为数不多的“男性帮助”。
两名层级和经验明显更胜一筹的男同事，七嘴八舌贡献向老板道歉的话术，最好体现出感激之情和谦逊的态度：“我反应过度了”“我没有资格质疑您的决定”“感谢给我继续工作的机会”“保证不会让您再失望了”。
虽不好判断这些话里有几分真心，几分权宜，或者几分历史教训，但这两位男同事的确深谙如何保护老板疯狂膨胀的 ego，到了一种让人惊悚的程度。
老板很快给简回了一封邮件，里面写着：“对不起，你很优秀，你非常优秀。我对你严格是为了让你变得卓越。”
这种操纵性的回应，很快在简那里有了反应：她的脊梁骨因为老板的夸奖重新挺直，她的野心和生活热情又重新燃起。
当稍后她跟老板的司机确认接送时间时，这位司机说出老板认为简很“聪明 ”时，这个落魄的小助理几乎是可怜兮兮地，感谢这句二手的赞美。
无论是辱骂还是赞美，这两种攻击人心智却形式截然不同的套路，相互配合，共同打击着简的自信和尊严，确保她安心地保持在自己的位置上。
在细雪纷飞的寒冬，在黎明前从皇后区公寓到曼哈顿办公室的漫长车程中，影片捕捉到简蜷缩在公司的车内昏昏欲睡的模样，她的身影渺小而苍白，被高耸的摩天大楼所掩盖。
她不是性侵受害者，但她也经历了漫长而惊恐的一天，被打量、调侃、责骂和无视。
而处在这个环境里的所有人，都围绕着全程隐匿的“大他者”，或急或缓，或对或错，不容置疑地活着——“他”从未出现，“他”无所不在。
安静克制的故事，表层下却是暗流汹涌。
这部电影的女主角，英文名叫 Jane，起这个名字背后暗藏英语文化的隐喻：plain Jane，意思是一个普通的女人；Jane Doe，则意为一个没有名字的女人，一个无名氏。
她可以是任何一个女人。
而我们，是谁的助理？又将如何被掠夺？
主要参考资料：
https://www.nytimes.com/2020/01/30/movies/the-assistant-review.html
https://www.theguardian.com/film/2020/may/03/the-assistant-review-julia-garner-kitty-green-me-too-office-drama-weinstein
https://borneobulletin.com.bn/assistant-quiet-powerful-look-workplace-harassment/
https://theartssection.org/home/2020/2/10/a-conversation-with-filmmaker-kitty-green-about-her-new-movie-the-assistant
https://www.vox.com/2020/1/29/21112386/the-assistant-interview-weinstein-julia-garner-kitty-green
*请认真填写需求信息，我们会在24小时内与您取得联系。
