Asciidoctor.js 暫時不可用

Asciidoctor 是一個由 Ruby 開發，基於 asciidoc 格式作解析、編譯成其它格式文件的套件。

有人利用編譯軟體，把 Ruby 的 Code 編成 javascript ，一切在一開都很美好。
一直到某一天 Google 的 V8 引擎作了改版…… 問題發生了。

Asciidoctor 在輸出檔案的時候，會加一個編譯時間的資訊。對於要查看哪個版本比較新，這是很重要。在輸出的時候，會去判斷輸出的結果是否帶有時區資訊，依結果作一些調整。

不過在 V8 引擎中加入本地化特性時，這個功能就出錯了。舊有的時區是全英文的，所以在執行 new Date().toString() 時，會得到類似「Fri Feb 24 2017 15:35:13 GMT+0800 (CST)」的字串。CST 應該是代表中原標準時間(China Standard Time)的縮寫。

不過現在得到結果會變成「Fri Feb 24 2017 15:35:13 GMT+0800 (台北標準時間)」，這導致 javascript  在判斷資料時，會認為回傳的結果有帶時區資料(這是對的)，但是偏偏不認得這個時區代表什麼(這就糟了)。所以會導致編譯的時候發生會終止程式的錯誤。

結論就是無法順利産出結果。就目前的狀況，除非是直接修改 Ruby 程式，重新打包 javascript ，或是全部用 javascript 重寫一遍(不用轉譯器)。否則這個問題無解。

至於為什麼認為是 V8 引擎的問題呢？這是因為更早些時候，我在使用 asciidoc 在 chrome 的官方套件時，同樣遇到這個問題。今天又在 node.js 環境中遇到，所以導致問題的原因，就該是兩者共同使用的核心，V8 引擎了。

學習程式也是需要好的切入點

分享一個連結…

https://plus.google.com/104192586349074807721/posts/MEKkeE86kJo

這也是我最近的寫照…

由於這幾天手上沒有要趕工的案子，就把這些時間拿去研究之前用到，但不夠了解的程式框架。而結果就如同連結裡的那些人一樣，不知道要如何下手，滿滿挫折感。

因此上周又再跑了一次書店，去看看有沒有能夠幫助我突破的書。曾經我認為網路資源已經多到不需要再去看那些過時的資訊(尤其是中翻英的書，在台灣可能都晚了原版一年的時間)。但是我發現，我錯了… 過時的資訊依舊，這本來就不會在短時間有太大變化。只是網路上能夠讓我吸收的資訊真的太少。

相依性是學習 Linux 系統時候聽到的名詞，是一個很讓人討厭的事情。如果今天要安裝的軟體缺少某個相依套件，程式就動不了。得一層一層的找到缺少的那個套件，可能是因為不支援新版，或是程式只能在某個特定的版本下才行。對於一個初學者而言，每次安裝軟體都算是一個「考驗人品」的過程。
(當然啦~  相依性的問題我認為還是存在，但是已經好多了，不過套件管理系統好像有分裂得越來越多的感覺)

最近學習 Node.js 程式的過程其實也是這樣，往往一支程式會引用到幾個套件，它們又各自引用了其它套件。當我爬到第三層左右的時候，我就已經亂掉了。因為由那些相依的套件身上，已經看不到原來程式的目的，只能一點一點的猜使用這套件背景、原因、目的。
爬了一些文，有的可能可以找到一點歷史，有些可能就只是單純作者搜尋類似功能時，找到的吧！

沒有文章能告訴我，要理解程式，需要先看那些東西，那些東西可以先略過，或是先用什麼方式去記憶，未來再深入學習。往往花了大半天的時候，得到的只有混亂，腦子裡整理不出什麼有價值的資訊，就不用說是有系統性的學習了。

嘗試過由 Unit test 的程式去看，發現它也許可以作為證實心中假設，但不適合去作為切入理解程式的方式。

也許未來我看程式的功力變強之後，可以撰寫一些心得文件。能幫助到和現在的我一樣的人就好了。畢竟人家寫出免費、好用的程式已經夠累了，要寫出有系統性的文件真的不容易，又很花費時間，還是大家想看的人，自立自強的比較好。

當然啦~ 如果現在就有那種能夠提升爬別人程式的文章，能夠解決我現在的困境就更好了。
這樣就不會讓我在那一直不斷的拿頭去撞這堵不知何時會倒的牆了…

重新出發

經過許多次 Blog 文章的寫寫停停，發現到要持續地寫點東西，實在不是一件容易的事情。
隨著年紀與社會經驗越來越多，生活漸漸變得複雜的同時，對於未來卻變得更模糊。

並不是沒有任何靈感出現，也不是沒有新知可以分享。
而是它都變得比從前更加地分散，碎片化。頂多只能在心中留下一個隱約的輪廓，要再將它整理成一篇簡單、明確的文字。已經超出了我目前的文字功力了。

可能是因為好一陣子沒有打文章了，也可能是日子過得太亂了，也不排除是因為對於想打出的文章中，結構、主題甚至是排版都有了更高的標準。

而一次又一次的無法達標，是一件讓人覺得挫折的事情。
只能再一次的灰頭土臉地，試著站起來，四處看看還有哪些是沒作的，還沒嘗試過的。

真的，不知道成功的未來是不是在路的盡頭，也只能硬著頭皮去走看看了。

回到打文章上面，一直以來，我都想要經營一個由自已主導，能夠分享不同於別人想法技術部落格。雖然目前為止文章裡的含金量不算沒有，但還遠遠低於我所期望的。
是得作點改變，或是改進作法吧~

和自已的工作有點關係，由最初的 PHP 到 Android 到 Java 到如今 HTML5 Javascript 為主的程式生涯，跳得語言太多。底子不夠，內向的個性也讓我沒有跟上資料爆炸的車。因此評估自已目前的功力，已經遠遠算不得是前段班的了。

不過同時自已也發現，現在想要追上那些神人，以中文而言，好像沒有太多論壇或是討論區能夠參與，不是我這種宅在家裡的人可以快速提升自已。
說實話，就算是要提升，也得先找到一條合適的方向，偏偏這對目前的我來說，也是個大問題。

因此，換個角度來說，把這段過程中自已想法記錄下來，似乎也是個可能性。
來嘗試看看吧！ 或許可以給某個人，或是未來的自已一些幫助。

當然囉~ 也許哪天我會重新建一個符合我希望的 Blog 站，有著我覺得理想的輸入模式。
這中間把一些想法打在這上頭，誰也說不準未來是如何，但總得要求自已不斷走出去，不是嗎？

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 下 "." 開頭的檔名是不合法的問題。撐了許久，最後決定爬原始碼之後才發現，暫時解決了這些問題。

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