i18next 不進行跳脫處理

i18next 是一個 JavaScript 框架，可以進行多國語系的翻譯。最近工作上進行的專案就是使用它來完成。不過被人發現到一個 Bug ，輸出的文字，有些時候會冒出 HTML 的 <br/> 標籤。查找了一下，發現到是出在傳入作為翻譯參數的文字造成的。

作為翻譯的文字中，可以使用 {{變數名稱}} 來為翻譯的文字加上參數。如：

{
  "HELLO": "Hello, {{name}}!"
}

var output = i18next.t("HELLO", {name: 'Tim"});
// output = "Hello, Tim"

這種方式可以讓同一個翻譯設定變得更有彈性，不過相對的也可能帶來一些安全性的風險。因此 i18next 預設會將傳入的參數（上面的例子就是 name 參數）進行一些跳脫處理。像是將 < 變成 &lt; 來避免所謂的跨網域攻擊問題（XSS）。

而我的專案遇到的問題，就是在於我傳入的字串，中間包含了排版用的換行字元。
因此導致被 i18next 給處理掉了。

要避免這樣子的狀況，目前找到的作法，是在參數的名稱加一個減號，這樣 i18next 就不會對傳入的資料作處理了。

{
  "HELLO": "Hello, {{- name}}!"
}
// 一樣的呼叫方式， name 參數傳入的資料，就不會被處理。

當然這樣子的作法，有可能會引入一些安全性的問題。所以要注意使用。

寫文章

遙想十多年前，還是大學生的我剛學會了 BBS 的使用方法，覺得新鮮的我，開始試著在上面發表自己的文章。一篇、兩篇⋯隨著文章的發表，打字速度的提升，慢慢我的文章越來越長，開始把自己的一些平常的想法，放在剛建好的個人板上。

既使被一些朋友抱怨過文章太長，文字太多也不以為意。只覺得那我個人想法的舒發，不以作家為職業目標的我，文體和用字就不需要太在意了。當時我並沒有想到，那段時間是我打字最快，也是寫文章最舒暢的時光。

後來試著改變過文體，也在入了社會之後，試著以技術分享為主題發表了一些文章。不過想不到總是沒有辦法抓到一個理想，能讓我續持寫作的感覺。以至於擺脫不了斷斷續續的毛病。光是這個 Blog ，也好長一段時間沒有更新了。

中間當然不只一次的立志好好寫點東西，筆記的形式、教學的形式、生活雜感產生的心得分享，都曾經是被考慮成為這個 Blog 的主軸，顯然的，最後這些想法都以失敗告終。不是一段時間內都找不到靈感，就是一直沒有累積、歸結出能夠拿得出手的結論。空了一陣子，就是連自己都忘了要好好寫點東西的初衷。

會回來打這篇文章的裡理，也是在意料之外。為了工作忙碌了好些年，事情卻沒有都上軌道的感覺卻總是揮之不去。學習力並沒有如經驗增加一般地漸漸提升，反而在一些技術驗證上，常常出現愄首愄尾，遲遲沒有付諸實行的情形。

發現到，我被這個社會「一作就只能成功」想法給制約了，變成一個只犠牲成就結果，而忘了也要試著享受中間過程的人。

所以，我想由鍵盤敲下這篇，沒啥大道理，也不具有任何結論，不預設要哪個人看，甚或能不能產生什麼正向幫助的文章。單純的想找找、享受回從前那種把心裡想法藉文字釋放出來的輕鬆感。也許哪天會找到幾個能持續撰寫文字的主題，但希望這股寫文章的好感覺，能夠被一直保留下來。

嘗試的精神

大約是這幾年吧～在前一份工作的時候漸漸覺得自己的學習能力開始下䧏，對於程式理解變得越來越慢，對於自己寫出來的東西感到不踏實。本來猜想是因為進入到以往不熟悉的領域導致的正常現象，直到換了工作過了一年，才隱隱覺得其實不是這樣。

對於從前常用的 PHP 語言，我依然有不太差的反應，能給別人建議，甚至對於一些我從來沒接觸過的部分，也能提出想法。以往帶人的 Live coding 感覺，也能如自己預期一樣進行。反倒是後來學的 Java, javascript 就沒那麼有把握了，往往一卡住就是幾個小時到幾天的時間。

總不可能是因為語言帶了「Java」就成了我的弱點了吧！程式的撰寫畢竟是一個偏向科學的工作，超自然的影響應該不常在這種地方發生。

上周打算把剛學的 Electron 拿來作個簡單的 Asciidoc 閱讀器，不過才剛開始沒多久，連環境都還沒建置完成就宣告失敗了。原因是我打算使用 Asciidoctor 提供的 chrome extension 來組合出成品，不過 Electron 並不支援 extension ，所以還沒下載完 npm 套件，就宣告這個計劃的結束。

事後覺得自己很瞎，一個開新瀏覽器新視窗就可以達到的功能，實際上並沒有太多打包成應用程式的必要，還是一個肥大的應用程式。如果早一點想到，也許連嘗試、下戴套件的時間都可以省下來。

事情總不只一個面向，幾天前的想法就在稍早洗澡的時候被推翻。這個不成功的嘗試不單不會全然無用，反倒是點出了我現在正缺乏的東西。

要不是我有了這個想法，我不會知道 Electron 不支援 chrome extension 引用這點。也許這個資訊有些微不足道，但是積少成多，就成為我現在所擁有的全部知識。而我現在覺得學習速度變慢，主要的原因出在我已經越來越少去作「嘗試」了。

前一份工作的形態，讓人缺少嘗試新技術的空間，大多時候都是儘量用自己已有的知識來解決問題。其後一些政策上的因素導致心灰意冷，用新方法解決問題的念頭也越來越少。自然，學習速度也一點一點的慢了下來。

不計成敗的嘗試，一點一點發現自己的不足之處去改進。我想，才是最適合我成長的方式吧～在這裡打打自己的心得也是，練習用文字來表達，練習歸結出自己零散的想法。

學習 Elecrton 的一些感覺

工作因素，自認對前端技術還不夠熟悉的自己，開始試著使用 Electron 這個能將前端技術打包成「AP」的工具來開發產品。一兩週的學習與測試，讓我仍然在許多方面處於混亂，摸不著頭緒的狀態。也許，改天把一些理清的部分的轉化成文章分享，不過現在我只想單純聊聊這中間的感受。

技術變革的快速，一次又一次打破我的想像。對於「AP」的印象，一直停留在 Access Point 這個網路設備的名字上，在這次的機會中，才知道原來「APP(Application)」一詞已經更廿廣的被使用在手機的 Mobile Application 上面，而 Desktop Application 則改用少一個字的「AP」了。

不得不說，手機的 APP 開發似乎比電腦用的 APP 還要熱得多。也許是還沒達到飽荷，有許許多多人想加入，在網路上的熱烈的討論，以至於常常佔用了搜尋結的版面，不知道哪個人決定使用「AP」作為縮寫，真是一個糟糕的主意。

Electron 是一個融合了 chrom （或準確一點的說，是它的開源專案 chromium），以及 Node.js 的開發工具。講起來很簡單，兩者都是具有各種平台的版本，所以把兩者的交集：Javascript 程式，以及用以呈現畫面的 HTML, CSS 技術，就能讓專注前端開發的人，使用平常就在使用的知識就能夠開發桌面應用程式(desktop application)了。

聽起來很合理，實際上也真的可以運作。不過是不是只要「前端技術」就能順利完成？個人是不太相信。這中間用了幾次我在其它領域學到的不完整知識，勉強地撐到現還還沒放棄。

要說會卡住的原因，我想一部分是來自於現在的我習慣於 Mac 上開發。又或著應該這麼說，似乎許多程式的開發者，都習慣於在 Mac 或是 Unix Like 的系統上開發。而導致一個作好的功能要移到 windows 平台的時候，才發現有許許多多的問題要解決。

寫程式嘛～解決問題本來就是理所當然的事情。Google 上有許多的問題與答案幫助工程師解決問題，但也是如此，當 Google 到答案都是無解或是斷頭(沒下文)的時候，就特別的讓人覺得焦燥。

得先作假設，再像是傻瓜一樣一個又一個假設慢慢去試。有時候半天過去了，最後還是一無所得，放棄的念頭浮現早已多到數不清了。最讓人無力的地方是，只知道程式不能運作，但是連卡在哪一個環節都不知道。

開源能夠成就很大行的案子，讓眾人的成果能夠像積木一樣堆疊成偉大的建築。在理想上，每個小片斷的開發者，只要完成自己那個部分，維護完美的狀態就行。不過呢，實際上每個部分都有可能因為開發者一個念頭的改變，或是單純的手誤造成後面的程式全盤出錯。

Node.js 就是我所知道最為混亂的地方之一，許許多多相似，又沒有用的功能，排在一起，偏偏沒有人能告訴你哪一個才能滿足需求，有時候讓我不禁去想，也許自己去把相關知識學起來，會比在這個大海撈針來得快一些。我想，可能不少開發者有一樣的想法，所以後來的人，就看到了更多相似名字，但依然不知道要如何選擇的模組出現在清單上。

本來我覺得，一個被多人肯定的模組，應該問題不大。不過就遇到一次因為沒有測試在 windows 的運作，沒有考慮到 Unix like 系統裡資料夾只是一種檔案類型，而 windows 不是的差別，也沒有預想到 windows 下 "." 開頭的檔名是不合法的問題。撐了許久，最後決定爬原始碼之後才發現，暫時解決了這些問題。

但是怎麼把這些修改後的程式碼弄回網路，通過原作者的審核，這又是另一個問題了。要學的東西真多，不過那裡就是接下來要研究的東西了⋯

在新年的一些反思

在幾天的放鬆日子後，開始試著找找自己生活的重心。持續忙忙碌碌的日子久了，忘了自己為什麼什麼而努力，想追求什麼樣子的生活。

看了幾集小說，看了一些佔用硬碟許久的動畫，也玩了幾個 RPG 類型的遊戲。忽然之間我開始思考一個問題：為什麼我對於這些東西會產生沉迷，不惜延後就寢的時間，犠牲睡眠就為了知道那個不會跑掉，改變的結果。

我猜，答案可能就在於，無論是小說、動畫，甚至是遊戲都有一個「確定」的結局吧！這樣的確定感，既使它們不過是「別人故事」，將自身代入主角的臨場感覺，也會讓人覺得「付出的時間是值得的」。

相比現實的生活，那些忙了半天一無所成，甚至得到反效果的情境相比。虛幻的世界要吸引人得多。就算知道人依然是應該活在現實的當下中，不過仍然抗拒不了到這些世界裡躲上一段時間的念頭。

就遊戲而言，目標與成果都明確，甚至有的有詳盡的攻略、密技。無論是努力的「練功」或是用現實的金錢成為「台幣戰士」，如果兩者皆無法答成目標，大不了換另一個遊戲就好。

就小說或動畫而言，主角光環會讓主角總能一次次的化險為夷，除非少數 Bed Ending 的狀況，大多都是「從此過著幸服快樂的日子」一般的結局。

對於人生的方向該是如何？生活中的每件事物各別應該分配多少比重？要犠牲到什麼程度，才叫作對工作負責？這些問題的答案，並沒有隨著「長大」而清淅，反而越來越模糊不明。到如今，連尋找答案的方向，都已經沒有數年前的自己那些有把握。

低頭向前衝了不知幾年，依然沒有「豁然開朗」地找到答案。一面思考是不是走錯了路的同時，也回頭看看自己是不是錯過了什麼，方向不見得是錯的，也許真的漏了什麼東西，是應該被發現的。

翻翻從前自己的想法，自己身上的能力累積地不算多，也不算一無所成，該找找那些從前的夢想，看那些曾經定下的志向，那些已經可以化作理想，成為可以一步步實現的。作最這陣子的短期目標。

至於那個「人生的價值」，可能得再過些時候，才能夠被看得清吧～

對 ES6 的程式作單元測試

距離「號稱釋出確定的規格」的幾個月之後，既使是在技術前端的 NodeJS ，也依然沒有完全支援 ES6 的所有語法。就不用說那些依附在 NodeJS 之上開發出來的模組。看到大多數的實作方法，靠 Babel 來作轉譯回 ES5 語法，再進行後續的工作。

對於我這種等級的開發者， Babel 背後運作的原理、語法分析的實作方式都屬於玄之又玄的事物。大多數只要結果正確的狀況，根本不會想去看懂那轉回 ES5 語法的樣子。不過事情總有例外⋯ 就是作 Unit test 的時候。

在我使用的 jasmine 模組中，錯誤訊息會帶有例外產生在哪個檔案的哪一行，對於查找原因是很方便的。不過一但轉換成 ES5 語法之後，每個指令不會在和 ES6 原始檔相同的位置，造成許多困懮，需要有「好心人」作轉譯的工作。

後來找到了 「jasmine-es6」這個模組，只要把它裝在 global ，就可以直接使用原來的 「jasmine」指令進行如原先一般的單元測試，出錯的時候也會對應回 ES6 原始檔的行號，很方便。

npm i -g jasmine-es6

jasmine-es6 本身會改變 jasmine 模組的程式內容。所以若是移除重裝 jasmine 後，要記得再裝一次 jasmine-es6 將擴充的功能再設定回去。

PS.
後來發現一個叫作 「jasmine-babel」的模組，讓我後來再安裝的時候搞混。雖然在 npm 上可以查得到它，不過對應的 github 路徑已經不存在了。應該是一個不再維護的專案吧～

另外，如果使用 gulpfile.babel.js 以及搭配相關的模組來以 ES6 語法執行 gulp task。其中 gulp-jasmine 能夠在沒有 jasmine-es6 的狀態下執行。不過我還不會用它來顯示錯誤的行號，不確定有沒有支援顯示錯誤在原始檔行號的功能。