marshawitd45o@outlook.com

口譯證照

外語學習迷思之4—跟阿豆仔學比力好嗎?

日文合約翻譯服務所以我們從發音, 語調乃至腔調, 都以美式英文為標準
說一口流利又好聽的外語是許多人戀慕的, 流利其實不難理解, 但好聽就比力抽象了翻譯社並且也很主觀.

法蘭克語翻譯演講竣事後不久，AYA 收到西班牙文系二年級學生 Alicia 的來信，她想知道具有第二外語能力對做商業有多大的幫忙？由於她自己主修的是西班牙文，她想瞭解西班牙文在國際貿易上的用途大嗎？台灣常做西班牙或是中南美洲的貿易生意嗎？
AYA 曾應邀到文藻的國際企業經管系去分享商業經驗，文藻是高雄享有盛名的外語學院，有英、西、德、法、日等列國語言學系，而國企系當然也有很多各外語科系的學生前來選修翻譯

荷蘭語翻譯無聊寫的，合適晚上睡不著的人催眠用翻譯包管對進修沒匡助，對領會 C++ 是什麼，有一定的混淆感化；大家沒事看看就好，不消在乎。 ◎貓抓老鼠－－沒有合適所有人的編程說話 經常見到許多人在問「天成翻譯公司應該進修什麼語言？」。雷同如許的問題，與 其說是「見仁見智」，不如說是「貓抓老鼠」。俗語說：「會抓老鼠的 貓，就是好貓翻譯」對使用者而言，事實何種編程語言是最合適的，端視 其小我的需求及能力翻譯要是始終拿不住耗子，這隻貓就算再寶貴，再漂 亮，也沒什麼意義翻譯 固然，反過來講，假如學欠好某種語言，也不必太甚灰心，這也許暗示 您應當測驗考試著轉往別的一片更適合自己的天空成長（另外一片天空，可能 是換養另外一隻貓，也多是換抓不同的老鼠，乃至可能是不抓老鼠轉業 養老鼠）翻譯但萬萬莫要因本身的挫折經驗，就拼命進犯抵毀它，特別是 當「這隻貓」早已被全部地球上業界頂尖的高手，和無數職業編程人 員及業餘玩家，證明了「它絕對是個好樣的」，適用價值無可代替時， 那些私心的談吐，只不外表露了批評者自己的偏狹翻譯 ◎其他主流語言與 C/C++ 的差別 在計議 C++ 和 C 的區分之前，也許先從「旁觀」者的角度，看看它們 「溝通」或「類似」的部份翻譯此處首要的參照體是選擇一般通用型的編 程說話翻譯 一、現實運作的概念 首先，從現實運作的概念，C 及 C++ 都是循傳統的方式，透過編譯器 和貫穿連接器，直接產生原生的機器碼（Machine Code 或 Native Code） ，而新一代的編程語言，有很多（例如 Java翻譯社 C# 等）是先透過翻譯轉 成 bytecode，然後再由虛擬機器（Virtual Machine）來執行翻譯 固然良多人認為 Java、C# 等語言依靠虛擬機械執行的方式，效率欠安 ，不過客觀的說，其實這種手藝在某種意味上是對照先進的觀念，它最 重要的優勢顯示在移植性方面。至於效力的問題多半出在各平台間的差 異太大，而實作技術則顯然還沒有完全成熟翻譯（但這是可以克服的） 可能已經有人起頭焦急了翻譯「照這樣說，C/C++ 不是後進了嗎？」其實 並沒有翻譯素質上來看，兩者是一樣的翻譯因為大可以把 C++ Complier 當 成虛擬機，只是它不是由一家公司或少數特定人士所規範的，並且絕大 多半的平台（機械和功課系統）上，都是撐持 C/C++ 的翻譯而像 J2SE翻譯社 .NET 這些架構則是 Sun 或 MS 所制訂的翻譯 （甚至可以如許認為：C/C++ 的虛擬機器是很多分歧廠商、組織各自實 作的，只是它們儘量遵守 ISO ANSI C/C++ 的標準，而 JVM 又或 CLI 這些東西，雖然說也是開放的，但實則操作在 Sun 和 MS 手中翻譯） 實際上，C/C++ 與 Java, C# 等最大的別離，並非體現在虛擬機械的 觀念或作法上，而是表現在應用層面。光學會 C/C++ 說話，乃至它們 的標準程式庫後，凡是幹不了什麼有效的事。一個 C/C++ 程式人員， 最少得熟習一種 GUI 框架、一種 IPC 框架及一種 Database 框架，才 大致可以說能處置大部分的應用問題。 固然，不是說用 Java, C# 就沒必要學會這些東西，只是這些功能有良多 都已經成為該說話（框架）標準的一部分，在學習語言的時辰，通常就 會順便學到利用的架構。但在 C/C++ 中，所謂的「標準程式庫」，卻 只規範了最最根基的 I/O，檔案處置懲罰，和常用的根蒂根基演算法等等，其他 都必需仰賴第三方或特定廠商的程式庫的支援，而這些器材則沒有所謂 的標準，又經常受限於特定的平台情況，在取捨上比力不容易。 二、型別系統的概念 C/C++ 語言都是採用傳統的靜態型別系統（static type system），而 很多新語言，為了便當物件導向特性的運作，是採用基於單根繼續的泛 化型別系統，例如 Object Pascal, Java, C# 都是如斯。 靜態型別系統的特征，就是不強迫改變利用者自訂型別（UDT: User- defined Type）的記憶體結構，而且允許在 stack 中設置裝備擺設 UDT 變量（ 也就是「物件」，但由於在 C 語言中，沒有真正物件導向的觀念，因 此以「變量」來指稱）。另外，在靜態型別系統中，「型別」和「變量 」之間，是壁壘分明的，翻譯公司無法在編譯期產生變量，也不行能在執行期 產生新的「型別」。 相對的，基於單根繼續的泛化型別系統，例如在 Delphi 的 VCL 架構中 ，所有的 VCL 元件，都擔當自 TObject，這就使得某些特別的功能，例 如以 ClassName 獲得物件的現實型別資訊，就很輕易實現。Java 和 C# 等也都是如此。某些說話乃至內建 MetaClass 的特性，型別本身也能夠 當作變量，在履行期建立新的、或修改既有的型別，這些都是本源於泛 化型別系統的根蒂根基。相形之下，在靜態型別系統中，良多特殊的功能， 語言自己不直接支持，就必需自己去實現，或仰賴函式庫。 當然，靜態型別系統的最大優勢，就是履行期的效力。這也就是 C/C++ 的「零本錢」原則：「利用者不應為他沒有效到的功能，付出履行期的 效力價格」。因為不是每件工作都得靠泛化型別系統的多態性來解決 ，並且解決的辦法也不該該只有一種（該語言所限制住的那一種）。 3、哲學的概念 簡單的說，C/C++ 的設計哲學是把程式人員視為「成人」。它認為程式 人員知道本身在幹什麼，而不是把程式人員當做「小孩」乃至「犯人」 ，需要特別的珍愛，甚至預設程式人員必然會犯某種毛病，所以它儘量 賜與最大的自由及彈性，而不是強迫的限制或規範。 例如，包羅內建型別，使用者自訂型別，和指標在內，它不強迫你必然 要將變量（物件、陣列或指標）初始化，不強迫翻譯公司查抄陣列的範圍，不 逼迫指標必然要指向正當的位址，它甚至允許你在各型別之間肆意轉換翻譯 又例如，C/C++它其實不內建垃圾收受接管器（GC: Garbage Collection）， 它認為唯有程式人員自己，才能決議何時方是償還動態申請記憶體的最 適當時機，而不會在背後監督著一舉一動，協助收破爛。 固然，如果只是因為「自由」和「彈性」，而要付出昂揚的管理和保護 的代價，那是不值得的。C/C++ 相對於其他語言，顯得較為「寬鬆」， 首要照舊基於效力方面的考量。許多基於物件導向特征的新語言，雖然 增添了平安和供給某些狀態下的便當性，但是一旦面對陌生或特異的問 題，既有的工具和規範，沒法直接套用時，過量的限制或「預設立場」 ，就極可能反釀成了累墜翻譯 從這個角度，也能夠說，C/C++（其實首要指 C++）其實不認為存在著某 種最完美的方案，可以解決所有「運用條理」的問題，是以其實不在說話 條理去規範這些問題應當怎麼解決，而是把解決方案交給運用層（程式 庫）去負責。說話自己只供給各類抽象的設計機制（介面），讓程式庫 的利用能儘量與說話系統的氣勢派頭一致。 ◎ 偉大的 C 說話 就筆者小我的認知，C 絕對稱得上是一個偉大的說話。它最偉大的地方， 在於說話自己，傑出地對映了 Von Neumann 所提出的現代計算機的模 型（首要是：二進位制、序列履行，以及將程式與資料都貯存在機械裏 ）。C 語言的指標（pointer），對記憶體操作的簡練、自由、及靈動 性，就充份體現了這一特點翻譯透過 C 說話，利用者可以較為直覺地運 用抽象的數學觀念，來編寫程式，而沒必要直接面臨艱澀的機械指令。 由於與機械模子之間的高度映照關係，和說話自己的精鍊，相較於機 器說話，C 除具有高度的移植性，在效能方面的施展闡發也相當凸起，大 部分的情形下，幾近不遜於機械說話幾何。許多大型的系統，除少部 份的焦點代碼利用機械說話以外，絕大部分都是以 C 說話編寫的。 以目前的目光，雖然 C 說話不是大大都應用範疇的首選（固然，照舊 有不少範疇是非常 prefer C 說話的），但透過 C 語言的進修，對於 理解程式在機械中現實的運作情形，有莫大的輔助，也可以說是理解程 式的根本翻譯任何人若想成為編程高手，精曉 C 說話，可以說是最少的 條件。在全部資訊科學範疇中，C 語言更是佔有極爲環節、沒法磨滅的 歷史性地位。 ◎從 C 到 C++ 固然其實筆者是很想下「偉大的 C++」如許的標題，但現實上如果不是 承繼了 C 語言的精華，C++ 是不可能有今天的成績的。另外一方面，C++ 的某些不盡人意的地方（例如語法的過於複雜），也是因為承襲了 C 語 言的特點才造成的翻譯 事實 C++ 和 C 有什麼不同呢？正本，在 ANSI C99 的標準之前（C89） ，C++ 至少有 95% 乃至可以說 99% 是兼容於 C 語言的，是以可以說 C 說話是 C++ 的一個子集。但在 C99 以後，某些 C 說話新的特性， 特殊是動態長度的 Array，使得這種大體上的兼容性被破損了，也就是 說，把 C 當成 C++ 的子集，如許的說法可能要有所保存了翻譯假如未來 ，C 和 C++ 再度泛起某些重大的不合，也不是什麼使人不測的工作。 1、強化「型別平安」－－對型別系統的周全改進 很多涉及語法細節的地方就略過了。在此只提出一個較主要的部分，是關 於 C++ 與 C 的基本分歧的地方： int *v = ...; void *p = v; int *p2 = p; // 合法的 C 程式碼，但在 C++ 中不正當 簡單的說，C++ 不答應 void * 隱式轉換為隨意率性型別 T 的指標翻譯但在 C 說話中，這是正當的。 C++ 制止上述操作的理由，是為了強化「型別平安」翻譯程式中一旦利用 void *，就等於主動放棄了編譯器對型其余主動搜檢與查對動作，也就 是摒棄了型別平安。而明知不好，C++ 依然支援 void * 這類用法的原 因，主要是為了兼容於 C，但由於 void * 隱式換為隨意率性型別的 T *， 這類用法其實太危險，所以在 C++ 中被制止了。 幻想的 C++ 程式，是不該該出現 void * 這類用法的翻譯C++ 之父 B.S. 就曾指出，除低階程式以外，應當儘量避免利用 void *，若是非得 用 void * 不可，凡是代表你的設計出了某些問題。 仔細觀測，C++ 的每一項根本設施，都有提升型別平安的意味在其中翻譯 例如： １引入 bool 型別，避免攪渾。（首要問題在函式 overload 時） ２勉勵以 0 而非自行界說的 NULL 巨集等代表空指標。（B.S.大和另 　一位 Herb Sutter 大，在 2003 歲尾提出新增添 nullptr 樞紐字， 　但不知道 C++03 是不是有通過）。 ３引入 const，讓「常數性」成為與型別不可朋分的一部份，除晉升 　平安，讓編譯器承當檢核的責任之外，也有助於代碼的優化翻譯（是以 　後來 C 說話也跟進採用。） ４引入 const翻譯社 inline 等用法，削減非需要巨集的利用。（因為展開 　巨集是預處理器的動作，沒有經由過程編譯器，也就沒有型別安全可言）翻譯 ５引入 reference 機制，簡化指標的語法，並有用削減指標（特別是 　兩層以上的複雜指標）的利用翻譯 ６引入 new 和 delete，取代 malloc 和 free，把動態記憶體設置裝備擺設的 　工作，提升至說話層級，削減強迫轉型的利用（另一首要目的是為了 　合營 operator overloading，晉升介面的一致性）。 ７引入新的 static_cast, const_cast 等樞紐字，鼓動勉勵儘量削減強迫 　轉型的利用。 ８引入 function/operator overloading 機制，讓同名函式及各類運 　算子，可根據分歧的操作型別，實現分歧的動作翻譯強調「型別」也是 　函式簽字的一部分，達成介面一致性，並使 UDT 能像內建型其它操 　作一樣天然。 這些每個小處所，都可以看出 C++ 為了強化「型別平安」，所支出的 用心和努力，固然除禁止 void * 的隱式轉型以外，根基上沒有限制 C++ 使用者延用舊的 C 說話的舊式習慣寫法，但筆者認為，認識型別系 統的特性，並隨時意識著「型別平安」，是把握良好 C++ 編程氣概的最 主要觀念翻譯 2、在「思惟方式」上的差異 程式說話處置的不外乎資料結構及演算法，STL 的發現人也說過：「程 式基於正確的數學。」前面提過，C 語言偉大的地方，就是它十分優越地 對映到機器模子，免除了直接使用機器說話的晦澀翻譯 也就是說，C 程式人員沒必要去費心 register 管理、記憶體定址等等極 度低階的細節問題。其所思慮的，多半像是「我應當用什麼演算法，把 某幾段特定記憶體內的資料取出來，顛末如何的運算後，再存到特定的 記憶體區段去……。」這種把運算和存取操作的細部具體動作，轉換為 抽象的數學思慮的流程，素質上依然長短常切近機械模型的翻譯而如許的 氣概，不但反應在 C 程式碼上，更多半根深蒂固地植入 C 程式人員的 思惟體例內翻譯 跟著資訊科學的發展，越來越多的運用問題，需要利用編寫程式來處置 ；人們發現，大部分利用程式所利用的演算法和資料結構，是極為有限 的。另外一方面，編寫程式說話的經常使用技能，卻已積累地相當做熟了， 程式人員需要支出更多心力的，不再是某個典型的演算法或資料佈局， 應當若何實現，若何處置；而在於，若何將問題的自己，恰當地轉換為 程式說話。 是以，一種讓程式語言可以或許以「切近待解決的問題」的方式來思慮，而 不再只是侷現於「切近機器模型」的思想，就應運而生翻譯簡單地說，它 就是起源於 70 年代（甚至更早），在 80~90 年月開始快速成長，直至 本日，雖不再新鮮，卻仍屬旭日東升的「物件導向」的觀念。 由於物件導向（OO: Object-Orientd）的觀念是如斯氾濫，甚至已上 升到哲學的條理，幾乎沒有一個比力新的說話（80年月以後），不支援 它的特征，所以這裏也就不多介紹了。只是要指出一點， C++ 也好，或 其他支援物件導向特征的編程說話也好，它們與 C 說話最大的劃分，並 不在語法或功能的區分上，而是在於對待問題的基本思考方式，也就是 所謂「思惟方式」上的差別。 三、multi-paradigm C++ 和 C 說話，在觀念上最大的分歧的地方，就是，C++ 是支撐 multi- paradigm 的編程說話。以下面所示，C 說話及傳統的 Pascal 說話， 是所謂 procedual-based 的編程語言，而 Java, C# 等較新的語言，則 是 object-oriented 的編程說話（OOPL）。 至於 C++，它現實上是個支援 multi-paradigm 的編程說話，因為它不 僅保留了 C 的法式導向的編程，更主要的是它沒有無為了要支援 OO， 而粉碎基於 C 語言的靜態型別系統，因此它供給的 ADT（abstract data type）機制，與擔當和履行期繫結等 OO 特性的機制是互相自力的。這使 得 C++ 在 OO 的履行期多型以外，罕有地提供了壯大的編譯期多型的機 制，也就是一般稱為「泛型編程」的手藝。 procedual-based（eg: C翻譯社 Pascal...） object-oriented（eg: Objective C翻譯社 Object Pascal, Java翻譯社 C#...） C++: procedual-based object-based(ADT) \ / \ \ / \ \ / \ generic object-oriented(OO) 由上面的簡單示意圖可看出，泛型（generic）的編譯期多型的特征，不 止對應在 ADT 上，也可以直接對應到程序導向的編程，例如 C++ 標準程 式庫所供給的泛型演算法，就大部分是以函式而不是 class 來出現的， 現實上，整個 C++ Standard Library，除 I/O 的部分，幾近完全沒有 用到 OO 的執行期多型的特征（更多的是 ADT 和 template）。 另外，也許有人會提出，其實 Java 或 C# 也是支援 generic 編程的，是 沒錯，Java 也有雷同 C++ 的樣板容器的功能，但現實上是用「代換法」 做的，並沒有真正產生新的型別，是以它沒法達到 C++ template 那樣可 以有型別客製化（特別化: specialization），或與其他抽象化機制合作 （例如擔當、乃至遞迴）的多樣化的能力，其實不算真正意義上的編譯期多 型。現實上，Java 和 C# 說話所採行的單根繼承的泛化型別系統，早就先 天限定它們不合適朝編譯期多型的標的目的成長，它們比較接近純粹的 OOPL。 C 說話的思慮體式格局偏重於資料運算和記憶體存取的動作，物件導向的思慮 體例，則是將問題分化成不同的抽象概念（class），讓使用者專注在概 念與概念間之的聯系關系，能從一個整體的大的標的目的，去存眷問題，避免過早 陷入細節，見樹而不見林。 同時，精良的設計，是當需求有所改變時，只需要點竄、調整部份的模組， 就可以完成工作，沒必要整體性的翻修，牽一髮而動全身。這也是物件導向 設計的主要精力，有一個專門的領域 DPs（Design Patterns），它與特 定程式說話無關，就是在研究面臨各類問題需求的典型解決體例，如今學 物件導向設計必然會接觸到它。 至於，C++「多思惟面向」（multi-paradigm）的特征，又是如何影響編 程的思慮體例呢？ 這裏舉個《Modern C++ Design》第七章的例子。Smart Pointer 的成長 念頭，是為了避免直接操作指標所帶來的危險性，但跟著各類不同的需求 ，它的實作細節也就有所不同。例如：它能不克不及與其他容器類（例如標準 程式庫中的 vector, list 等）共用，和使用的細節若何？是不是答應取 得原始指標？是否對各類操作動作進行搜檢，如何查抄？乃至，是不是支援 多緒程式平安地操作……等等。 假如將各類需求組合都列出清單，再一個一個實作，必將沒完沒了。最理 想的體式格局，是讓程式員自由選擇各種「需求策略」，讓編譯器主動產生相 應的程式碼。這類設計乍看來是遙不可及的抱負，但現實上已經做到了。 這就是 Loki 函式庫所供給的實作品 class template SmartPtr： template < typename T, template <class> class OwnershipPolicy = RefCounted, class ConversionPolicy = DisallowConversion, template <class> class CheckingPolicy = AssertCheck, template <class> class StoragePolicy = DefaultSPStorage > class SmartPtr; 由於牽扯的選擇項目過量，這裏只诠釋 OwnershipPolicy，也就是現實物 件擁有權的策略，它預設是 RefCounted，也就是參用計數的規則。但也 可以根據需求的不同，選擇其他的具有權策略，例如：RefCountedMT、 DestructiveCopy、DeepCopy、……等等。利用體式格局以下： class User {...}; typedef SmartPtr<User, RefCounted> UserPtr; 如此，UserPtr 就釀成近似 boost::shared_ptr<User> 的感化，可以和 標準容器合作，而實現 Java、C# 說話常見的功能。又假如： class Manager {...}; typedef SmartPtr<Manager, DestructiveCopy> ManagerPtr; 目前，MangerPtr 則和 std::auto_ptr<Manager> 一樣，採取所謂「摧毀 式複製」的語義，也就是同時只有一個 ManagerPtr 可以真正操作同一份 Manager 類型的實體物件。 現實上，SmartPtr 的實現牽扯到 ADT、多重繼承、編譯期多型等等的特 性，它運用了一種叫 policy-based 的設計觀念。這與其他程式說話或是 DPs 所標榜的 OO 的特性，或所謂「優秀設計」的終究目標，並沒有分歧 ，同樣是將分歧的概念自力分解，再奇妙組合起來。只不外，在 C++ 中， 除了傳統 OO 履行期多型的手藝之外，還多了壯大的編譯期多型的支援， 使得不但「物件」（資料結構和演算法），可以在履行期被彈性處理，就 連「型別」（概念）的本身，在編譯期，也能夠自由的拔取整合。這對程 式碼編寫的簡潔、靈動性和履行效率，都能帶來很大的提拔。

英語翻譯愛沙尼亞語要真正學好一種說話，照樣必需要透過大量閱讀這個語言所寫作的書，去進修該語言辭彙的恰當應用，因此，說話的進修離開不了文化，在進修一個新說話時，孩子會不知不覺進修到這個說話的文化而做出對這個文化的認同，有時兩者會有衝突，會產生一些母語文化不許可的行為翻譯例如美國人接到禮物是當場拆開來看而且表示極度的喜好，而我們中國人則是要三推四讓，再三推不掉才委曲收下，回家後才可以打開來看，絕對不克不及當客人面把紅包拿出來數，我兒子就犯過這個中國人的大忌。不外，文化上的衝突不是問題，孩子一教就會，這點從孩子很小就知道跟阿公講台語，跟菲傭講英語，跟老師說國語就能夠知道，他們應付得來的，有時，多接觸一些文化對胸懷的打開也有幫忙，有研究發現從小有不同國籍玩伴的孩子長大後，比力沒有種族岐視的偏見。
母語學習有敏感期

日語翻譯社 0010667654垂頭便見水中天：股票軌跡道盡一切

翻譯公司價錢

西班牙文翻譯1/2の確率　それじゃ踏み出せないね
 

英古什語翻譯看到天成翻譯公司的文章有被回應，心裡的感受真的比沒被回應來得要很多多少了翻譯 本來天成翻譯公司很懶得打字，不外後來我想想，還是來一篇有關說話交流的經驗和心得吧！ 本來一入手下手我想要交換的語言是英文， 想固然爾，在the mixxer（說話交換的網站）上多的是母語是英、美語的人， 很快地，我就找到了一個52歲的紐西蘭人，名叫James翻譯 就在天成翻譯公司們語言互換了一個多星期之後，他就封閉我了。 （以我的個性而言，我也封閉他了！） 緣由我很清晰，因為天成翻譯公司不太會讀漢語拼音。 接著，我不停地找partners，絕大部分不是不適合，就是本身跑掉了， 還有的人是明明聊得好好的，可是過沒多久就封鎖人的那一種。 就在某一天，我倏忽想到天成翻譯公司除英文以外，還可以學韓語， 無意中找了一個韓國人聊天， 在我加他為skype好友以後， 天成翻譯公司發現他跟天成翻譯公司一樣想要有曆久穩定的說話交流， 很幸運的是，我才找了一個，就不消不停地找partners了！ 我用the mixxer跟skype的心得是… 1.因為網路真的很利便，不是每一個人的立場都是正確及有禮的翻譯 2.若是真的有心要省錢及進修，partners跑了再找就有了。 3.partners要主動找，不是被動地等人來找翻譯公司。 4.我再分享我有註冊的說話交流的免費網站， http://www.sharedtalk.com/ 5.我不找太年青的人，並且我會找母語是我想學的說話的人當我的partner！ 6.要有耐心守候對方skype的回應，也不見得每一個人城市理你。 7.對於商定好的時候，要求本身準時泛起，但如果對方遲到，天成翻譯公司會等他10分鐘， 沒出現的人也先別急著封鎖他或從名單上刪除，有的人可能真的有事沒法呈現， 但他在過後會奉告緣由。 8.總而言之，「平時心」才是利用網路語言交流的王道。 其實我的心得良多，可是要天成翻譯公司全打出來真的是要我的命！ 今朝這些，我想應當就夠說話交流新鮮人認識…

翻譯設
有些科系的專業極度具有獨占性，是以非分特別的熱門翻譯然則請別遺忘了，他們在就讀時代，是何其艱巨，證照是何其難考。大夫、律師、建築師、工程師，哪個不是汗水與淚水換來的工作？我們常常健忘了他們的淚水，而只看到了他們鮮明的頭銜。