整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
前記得有跟大家介紹過一款號稱終端神器的一款軟件 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小時內與您取得聯系。
