Category: 翻譯
-
James Taylor - Carolina In My Mind 歌詞中文翻譯
In my mind I'm gone to Carolina Can't you see the sunshine? Can't you just feel the moonshine? Ain't it just like a friend of mine To hit me from behind? Yes, I'm gone to Carolina in my mind 在我的腦海中，我已到了北卡羅萊納 你能否看見陽光？ 你能否感受到月光？ 這不就像遇到許久未見的朋友嗎？ 對啊，我已回憶起北卡羅萊納 Karin, she's a silver sun You best walk her way and […]
-
隨著抗議仍然持續，伊朗死亡人數上升
from Alijazeera - Iran death toll rises as protests continue 在伊朗各個城市上週開始的全國性反政府抗議活動中，至少有九人死亡。伊朗國家電視台證實星期四在襲擊卡德利詹 (Qahdarijan) 市警局的過程中，有六名抗議分子 (demonstrators) 死亡。 根據官方傳媒的報導，暴動分子 (rioters) 嘗試進入警局取得武器。 在霍梅尼沙赫爾市 (Khomeinishahr) 則有一名 11 歲男童以及 20 歲男子遭到殺害。 根據報導，一名伊斯蘭革命衛隊 (Iranian Revolutionary Guard Corps (IRGC)) 士兵在納傑法巴德 (Najafabad) 遭到攻擊者以狩獵步槍射傷。該地位於伊朗首都德黑蘭以南 350 公里。 不過，半島電視台無法獨立查證該名 IRGC 士兵是否就是星期一由半官方新聞組織 Mehr 通訊社所報導的遭到射擊的同一個警察。 接下來的六天示威中，只少有 20 位民眾遭到殺害，以及大約 400 名示威者遭到逮捕。 自動盪開始以來，大約有 450 人遭到逮捕，由德黑蘭政府相關單位給出的數字為：星期六 200 人、星期日 150 人、星期一 100 人。 伊朗其他城市的居留人數則無法確認。 週一的集會 儘管 […]
-
The experimental generation of interpersonal closeness: A procedure and some preliminary findings
原文：Aron, Arthur, et al. "The experimental generation of interpersonal closeness: A procedure and some preliminary findings." Personality and Social Psychology Bulletin 23.4 (1997): 363-377. Intro 本實驗提出一個實用的方式來建立人際親密關係。一個人是否處於一段關係、特定關係中的個人配對，以及關係發展的情況則是操縱變量。在一個 45 分鐘的對話中配對間會根據關係建立的任務逐漸的將自我揭露情況提升。.....。 總之 ─ 自我揭露的對話比起普通談話來的有效。 以下幾種事情不影響親密感的建立： 約定、或是重要的事情 普通談話 相互本來就有喜歡 (或是不喜歡) 「建立親密感」本身是一個任務與否 hacker news: How to make a friend fast How to make a friend fast - […]
-
The Experimental Generation of Interpersonal Closeness - Appendix 翻譯
原文：Aron, Arthur, et al. "The experimental generation of interpersonal closeness: A procedure and some preliminary findings." Personality and Social Psychology Bulletin 23.4 (1997): 363-377. APPENDIX 說明：(開始實驗前請詳細閱讀說明) 這是一個有關人際關係的研究，而你的任務 ── 我們認為這應該會是一個愉快的體驗 ── 簡而言之就是要親近你的夥伴。我們認為讓你與你的夥伴親近最好的辦法就是讓你們雙方互相分享事情。當然，當我們建議你更為親近你的夥伴時，這個建議僅限於建議你在這個示範裏面的行為而已，我們並沒有要建議你於示範之外的行為。 為了讓你們更為親近，我們將會安排你們兩人進行一種分享遊戲。這個遊戲將會進行約一個小時的時間，結束後我們會請你填表來看看是否有更接近你的夥伴。 你們將會獲得三組題組，每一個題組都有一個題目或任務寫在上面。當你們兩人都看完這個指引，你們應該從 Set I 開始。其中一人應該念出第一個題目然後一起做出任務需求，從念出題目的人開始。當你們兩人都結束後，開始第二個題目 ─ 其中一人念出題目並且一起做出題目要求 ...etc. 當你們在作答時，請不要略過任何題目 ─ 依照順序作答。如果題目問你一個問題，請跟你的夥伴分享你的答案，接著讓他與你分享他的答案。如果是一個任務，則先做，做完後讓你的夥伴做。你們兩人應該請交互著念題目（並且作答）。 你們會被告知什麼時候需要移動到下一個題組，有沒有在時間內作答完畢並不重要。在每個問題花上一點時間，根據題目來週全而細膩的作答。 好了，你可以開始作答了！翻到 Set I，第一題。 Task Slips for Closeness-Generating Procedure Set I 讓你選擇世界上任何一個人，你會選擇與誰共進晚餐？ […]
-
深入 GIL: 如何寫出快速且 thread-safe 的 Python - Grok the GIL: How to write fast and thread-safe Python
本文將會探討 Python 內部的 Global Interpreter Lock，以及學習其如何影響 multi-threaded 程式。 原作者：A. Jesse，Twitter: @jessejiryudavis 原文：Grok the GIL: How to write fast and thread-safe Python Louie Lu 經作者同意[1][2]翻譯為正體中文。 當我6歲時，我有一個音樂盒。我將他上緊發條，在上面的芭蕾舞者開始繞圈，而盒子內的機關開始敲打，發出「一閃一閃亮晶晶」的聲音。雖然這東西肯定很廉價，不過我喜歡這個音樂盒，而我想要知道他是怎麼運作的。總之，我打開了這個音樂盒，看到了裏面的裝置 ── 一個我拇指大小的金屬圓筒，安裝得當的讓他可以旋轉，透過凸起的牙齒與鋼梳撞擊後發出音符。 在程式設計師的特點中，關於事情如何運作的好奇心是必不可缺的。當我打開我的音樂盒觀看內部時，我展現我可能是一個 ── 如果不是一個頂尖程式設計師 ── 起碼也會是好奇的一個。 這很奇怪，我在對 Global Interpreter Lock (GIL) 誤解的情況下寫了 Python 程式這麼久，因為我還沒有足夠的好奇心來了解他是如何運作的。我遇到很多人跟我有著同樣的猶豫，以及無知。 該是時候把這個黑盒子翹開了。讓我們閱讀 CPython 原始碼來了解什麼是 GIL，為什麼 Python 會有，以及他是如何影響我們撰寫 multi-threaded 程式。我會給出一些範例來讓你了解 GIL。你會學到如何快速寫出 thread-safe 的 Python，以及如何在 threads 與 processes 之間選擇。 […]
-
開發人員的面試指南 - A developer’s guide to interviewing
另一個標題：如何面試一家公司。 原作者：Dave Smith，Twitter: @djsmith42 原文：A developer’s guide to interviewing Louie Lu 經作者同意翻譯為正體中文。 譯註：本文描述為美國之情況，不一定能直接套用於台灣環境。 你有沒有過，當你在面試的時候，面試官坐在桌子對面，雙眼注視著問你：「你還有其他問題嗎？」，而你回眼回去並說：「umm, 大概沒有了」。如果這曾經發生在你身上，你有很大的機率得到了一個單一面向的面試經驗。 作為一個應試者，可以想見你把目標放在一件事情上：取得工作職缺。但是別忘記，面試並不是一個單向的工作。如同面試官在面試你，你也必須要面試公司。 不過，你需要問他們什麼呢？ 許多在尋找工作的開發者都問過我這個問題。在過去的 15 年內，我曾在 7 間公司工作 (包含兩個實習以及一個六個月的新創公司)，並且面試過無數次。我最後決定寫下我在這些面試中問的問題，好幫助其他面試者，並且期望對他們會有所幫助。 我的目標是將這些資訊記錄下來。如果你有任何的建議，請透過 Twitter 讓我知道，我會將資訊列入，讓大家都能受惠。 你跟誰談話？ 當你在面試的時候，通常會遇到下面三種不同的人。根據公司的規模，這有可能是一個人或多位人選： 軟體工程師 大頭 / 管理階層 (technical lead, middle manager, director) 公司領導階層 (VP, CTO, CEO, department manager) 下面的列表中，針對不同的人，我有不同的問題詢問他們。注意到，有些問題我會在不同人之間重複詢問，然後比較他們之間是如何回答。 這是一篇很長的文章。 比較像是一份 reference，而不是一篇拿來閱讀的文章。如果我今天正在面試，我會將這份指南帶在身上，然後 (謹慎的) 在面試中使用裡面的提問。 大部分的問題沒有所謂「對」或是「錯」的答案。它們被設計來讓你更了解整個公司的文化、流程以及組織架構。它們也能拿來當作一個對話的開頭，這在你的大腦因為面試而呆滯的時候會有些幫助。 基於禮貌，我通常會在面試開始時跟面試官說，希望留下時間來問問題。這能幫助面試官規劃如何面試。通常他們會把提問的時間放在面試的結尾，要對面試官的流程有認知，並且讓他們在早期就知道你的意向。每個問題結束後，詢問他們是否可以繼續詢問問題，以及還有多少面試時間。 針對軟體工程師的問題： 你如何知道你每天要做什麼？ 這個問題的目的是要了解有無工作流程上的障礙 (dysfunction)。我會希望從 […]
-
如何寫一個 Git Commit Message
原標題：How to Write a Git Commit Message, 31 Aug 2014, By Chris Beams 英文原文：https://chris.beams.io/posts/git-commit/，中文翻譯經作者 Chris Beams 同意。中文翻譯經 Yung-Ching Hsiao 協助潤飾、修正。 導論 | Git 7 條規則 | 小技巧 導論：為什麼好的 commit message 很重要 如果你隨機挑一個 git repo 的 log 來閱讀，你大概會發現它的 commit message 是一團糟。舉個例子，看看這些我以前 committing 到 Spring 的 gems： [crayon-6568419dd0a0b994138728/] Yikes. 跟我最近在同一個 repos 的 commit 相對比一下： [crayon-6568419dd0a10218027326/] 你覺得哪種看起來比較舒適？ 前者無論是在長度或結構上都很糟；後者則是簡明與一致的。前者是大部份情況下會發生的事情，後者從不會偶然發生。 […]
-
中文翻譯 - 9 lessons from 25 years of Linux kernel development
原文網址：https://opensource.com/article/16/12/yearbook-9-lessons-25-years-linux-kernel-development Posted 14 Dec 2016 | Greg Kroah-Hartman 註：作者 Greg Kroah-Hartman，曾經來台在 COSCUP 2013 演講，是許多 linux tree 的 maintainer (usb driver core, debugfs, sysfs...etc)，同時也是 staging 的 maintainer (staging 裏面有個地方是給新手練習 submit patch 的，greg kh 也會在 newbie mailing list 上解惑)。 他也是 Linux Device Drivers 跟 Linux Kernel in a Nutshell 的作者，台灣有翻譯前者，不過兩本書都很老了 (2.6的年代吧)，他自己也有說LDD 4rd 近期大概不會出版QQ。 可以說 Greg KH 在 Linux […]
-
測所翻譯 - Testing on the Toilet: Web Testing Made Easier: Debug IDs
原文網址：https://testing.googleblog.com/2014/08/testing-on-toilet-web-testing-made.html Tuesday, August 12, 2014 by Ruslan Khamitov 在每個元素中增加 id 可以讓針對網頁的測試更易於操作 DOM (e.g. WebDriver tests)。考慮到下面兩個只有內文有差異的 DOM： Save button Edit button [crayon-6568419dd102a332281801/] [crayon-6568419dd1030228805122/] 在這個例子中，你會如何使用 WebDriver 來與 "Save" 按鈕互動呢？你有許多的選項。其中一個選擇是使用 CSS selector 來互動： [crayon-6568419dd1031952603238/] 但是，這個方法並不足以認出一個特定的按鈕，而且沒有其他機制可以讓你在 CSS 中以其中的文字過濾。另一個選樣是使用 XPath，這個方法非常的脆弱且不鼓勵使用： [crayon-6568419dd1033488605447/] 你的最佳選擇是增加一個獨特的階層式分類 ID，每個 widget 會有一個 base ID，而這個 base ID 會成為其子元素的前綴。以剛剛的按鈕為例，他們的 ID 將會是： [crayon-6568419dd1035612371062/] 在 Google Web Toolkit (GWT) 中，你可以在你的 widgets 覆寫 […]
-
測所翻譯 – Testing on the Toilet: Writing Descriptive Test Names
原文網址：https://testing.googleblog.com/2014/10/testing-on-toilet-writing-descriptive.html by Andrew Trenk 先來個問題：你要花多久時間來理解下面這個測試程式要做什麼？ [crayon-6568419dd1235132394770/] 你大概閱讀了每一行程式 (說不定不只一次) 然後才理解每一行在做什麼。不過，如果一個測試有好的名子，你需要多少時間來理解下面這個測試想要做什麼呢？ [crayon-6568419dd123b381177690/] 透過良好的命名，你應該可以只透過閱讀測試程式的名稱，了解這個測試程式的想要測什麼，你甚至不用閱讀他的程式碼。前面提到的測試程式名稱只說明了他想要測試的情境 (scenario) 是 "invalidLogin"，但沒有真正的說明他期望的測試結果是什麼，所以必須要閱讀所有程式碼才能了解他的意圖。 將情境以及預期結果放在測試名稱還有其他的好處： - 如果想要了解一個類別所有的可能的行為，只要閱讀他的測試類別 (Test class) 中的測試名稱就可， 相比於原本需要花費數分鐘甚至是數小時來閱讀測試程式甚至是該類別本身來理解其行為。這對於 code reviews 也是有幫助的，因為你可以快速的了解是不是測試都已經覆蓋到所有可能的 cases。 - 藉由給予測試更為顯式的名子，可以強迫你把一個測試許多不同行為的 testing 拆分為不同的測試。 不然，你可能會想要把針對不同行為來測試的斷言放在同一個測試程式內，時間一久，這會讓整個測試程式膨脹且變得難以理解與維護。 - 測試的行為不一定每次都能從程式碼中清楚的了解其精確行為。如果測試名稱沒有顯式的告知其精確行為，有時候你會需要猜測這個測試到底在做什麼。 - 你可以簡單的了解到還沒有涵蓋進測試的功能。如果你沒有看到測試名子有那個你想要看或測試的行為，那你就知道，這個測試還沒有被實作。 - 當一個測試失敗的時候，你可以立刻知道是什麼功能失效，而不用去看測試程式碼。 . 有許多的 common patterns 來維護一個 test 的名子 (一個方式是，用英文句子中 "should" 的方式來命名，e.g., shouldLockOutUserAfterThreeInvalidLoginAttempts). 不論你用那種 pattern，同樣的建議依然適用：確保測試程式的名子包含了測試情境以及預期的結果 (Make sure test names contain both […]