過程重於結果

最近看書看到一個說法,說失敗是一定會發生的,練習是為了讓失敗在這個時候發生,讓失敗的「次數」被用完,那麼實際執行的成功幾率就高了。

雖然有些奇怪,但也是有些許的道理。練習的過程中,如果總是成功,那麼在未來遇到問題的時候,就少了解決問題的能力。

因此,失敗是有必要的,也是無法完全避免的東西。

延申而論,去期待每一次的練習,實作都能夠達到設定的目標,其實是一件不切實際的事情。我這才發現自己之前許多事情無法持續的主要原因之一⋯

閱讀全文〈過程重於結果〉

回頭打基礎

早在大約二年前,就有聽說 webpack 在打包 ES6 格式的 javascript 可以不需要使用 babel 就可以了。當時沒有深入去探討其中的原因,也沒有特別花時間去測試。因為現有的專案已經在使用 babel 了,動那些存在已久的設定檔,是一件讓人很有壓力的事情。

最後⋯就不了了之了。

一直到最近,為了解決 electron 開發環境建置中遇到的問題,決定從零開始搭建專案目錄裡的東西。本著沒用到的 module 就不安裝的想法,一步步完成環境。隨著環境的建立到現在,已經採用了 ES6 語法開發的狀況下,目前還沒有安裝 babel 套件。

閱讀全文〈回頭打基礎〉

找回 Electron 回來學習

對於一個已經發展有一段時間的專案,越來越沒有能夠簡單測試的項目。所以謂的簡單測試,指的是單純使用重整或是 API 要求就能夠驗證的東西。用程式開發的角度來說,就是要測試的東西「並非純函數」,總是會相依一些東西或操作。

因為使用帳號的不同,或是服務選項的改變,回傳的結果也會有相應的改變。這是再正常不過的事情,麻煩的地方是在驗證的時候,常常要進行一連串包含登入在內的操作,才能讓服務中,帳號當下的「狀態」變成測試需要的樣子。一旦修改服務的程式,服務重啟後,同樣的行為又要再來一次。

不複雜的流程下還能接受,只是在調整不熟悉程式的過程中,隨著需要不斷的微調 – 重啟測試 – 定位問題 – 再微調 的過程中。那些與測試目標無關的行為(包函登入),就會吃掉許多工作時間。影響到開發時間是一回事,容易讓開發者不耐煩造成許多 bug 出現的狀況更需要避免。所以想要作個簡單測試工具,把一些常見的流程自動化,所以想了一想,把早期曾經用過一小陣子的 electron 技術出來重新學習。

閱讀全文〈找回 Electron 回來學習〉

與原文技術文件打交道

這陣子給自己加了一個「小目標」,把 PHP 的官方文件大致看過一遍。至少是比較會使用到的基礎部分。若是遇到那種寫外掛、寫桌面應用程式的部分,如果真的太難還是選擇跳過。

頭幾篇的文章,為了有更好的效率,所以選擇看簡中的版本,不過一篇沒有看完,就決定回去看英文的原版。和自己正式試著翻翻 MDN 文章,所以正在強迫自己看英文有一點關係,一來是覺得文章的內容比起英文的版本容易落後一段時間,另外就是目前看到的人工翻譯,品質並不是很好。

品質不好的原因有幾個,猜想比較有經驗,看得懂英文的人就會直接閱讀英文。所以剩下來翻譯的人,一來英文不見得很好,二來對這個語言的了解也不夠。一些文字的掌握上的不足,就會產生偏差。因為自己還算多一點經驗,不會把課程中的「單元」與程式概念裡的「模組」這兩個都會用到 “module” 這個翻成同一件事。

所以在這沒有處理好用語的中文翻譯,就會出現那種每個字都看得懂,唸得出。但偏偏整句合在一起就不知道在表達些什麼的狀況。最後要嘛是「領悟」到了真意,要嘛就是回頭去看看原文是說了什麼。導致看這類相對品質低了一點的翻譯,有時候反而比看原文還累得許多。

有時候會,會讓我有種錯覺。好像回到大學的時候,有堂課上課用的原文書,老師讓大家分組將每周的進度翻成中文的狀況,每周都能看到一些不知道意義的翻譯(大多是翻譯機的結果,甚至有的完全沒有修改),最後還是自己認命,去原文的內容。

隨著自己翻譯 MDN 的文章,偶而會發現中文的翻譯多了一些內容。可能是因為原文不太容易翻,或是翻譯者本身沒看懂,翻出一個語意怪怪的結果,然後再自創了另一段原文沒有的話再試著「圓回來」。每當我看到這個部分,就會把它修掉,因為我覺得既然作的是翻譯,就應該以不超過原文的原意來翻譯。

另一個理由則是原文並不是自己寫的,所以在翻譯的時候,通常不會知道後續的章節裡面有什麼樣子的內容。所以胡亂猜測的話,可能會讓後續閱讀的人感到不通順。這也是自己目前翻譯常遇到的狀況。因為不想一開始給自己太高的標準,看到什麼文章就直接先翻,等自己的英文水平更高一些,也許能達到更好的翻譯品質吧!

不同的作者,似乎也有不同的用詞習慣。像是 PHP 的用詞,就常常讓我得去查字典才能看懂, MDN 的用語似乎就淺了一些,漸漸開始能不靠查字典能翻譯一些簡單的段落。

最後一個感覺,小時候大家總是會覺得讀書是一個「不夠有效率」的事情,所以總是要求要「快速抓到重點」,減少閱讀的時間。也有了速讀之類的技巧出現。但是在閱讀原文的時候,一開始卻不能那麼急,得一個一個字都「看」過,而不能像母語一樣跳字來看,往往一些比較不熟悉的單字會被直接忽略,有時候會唸完了整段,結果不知道它在說什麼。

得花點時間去慢慢看完每個字,試著唸出來。自己會的英文單字不算太少。但是對於平常要使用,還是少了一些。得漸漸把那些單字的都學起來,才能夠更順暢的由原文的文件學習吧!

設定 gVim 的字型

前兩天在 mac 嘗試東西的時候,偶然發現了不錯的字型。想要套用到的 Windows 上的 gVim 裡面,
讓使用時候的心情能更好一些,誰知道裝完了字型,很尷尬的發現,我不知道「正確的字型名稱」。

不管是在 Windows 裡的「字型」或是 mac 裡的「字體簿」,字型都有它獨有的「顯示名稱」。
若是一般的文書處理,可以直接由下拉選單來設定,但是在偏程式類的設定,不光是 gVim,
像是 VS Code 也是需要知道字型的「真實名稱」,才能正確的指向。

閱讀全文〈設定 gVim 的字型〉

燒腦的感覺

最近換了工作,為了自己的要求,以及希望能在三個月後談到好薪水。這陣子努力地把自己還不熟悉,甚至還不會的東西裝進腦袋裡。加上最近花錢去學新的程式技術,排隊等著吸收的東西,又變得更多了。

不知道是因為自己的雜務太多,還是因為腦袋太久沒有的處理這麼高強度的事情,光是了解要學習的內容,就有一點點吃力,再加上不時偷偷襲來的睡意,會讓整個下午,甚至整天的學習成果大打折扣。

當喘口氣的時候,看著現在正在經歷的這段燒腦日子,老實說滿讓人懷念……有點仿弗回到高中時代,那個每天學習到暈乎乎,仍不知道自己學的這些東西,未來有沒有派上用場的機會。

閱讀全文〈燒腦的感覺〉

wifi 設定 3G / 5G 不同名

最近家裡的網路一直很不穩定,明明訊號不會很弱,但偏偏就是很常斷線。

還讓我以為是手機壞了,因為連不到的時候,手機會有點燙,放著吹吹冷氣一段時間就好。

直到換了手機後狀況依然,才驚覺問題不單純。查了一下 wifi 基地台的設定,猜想可能是其中 3G / 5G 的連線名稱一致的關係…

閱讀全文〈wifi 設定 3G / 5G 不同名〉

Mocha.js 與 Babel 7 的組合

之前的一段時間,為了單元測試的結果最接近實際結果,因此希望能夠與産品一樣在瀏覽器內進行,
因此使用 Karma.js 搭配 chrome 下執行,運作的時候會多一個作為測試的 chrome 瀏覽器。

後來覺得,既使使用 chrome 來測試,也不能代表在 IE, Safari, FireFox 下都能絕對正確地運作,
單元測試主要針對資料處理、數值運算的檢查,跑在同樣以 V8 引擎為基底的 Node.js 上應該沒太多差別。
就算小部分的不同,與少開啟一個瀏覽器所增加的測試效率相比,在 Node.js 下測試比較有利。

藉由將專案的 Babel 版本升級到 7,重新串接單元測試的流程,並將過程記錄下來。

閱讀全文〈Mocha.js 與 Babel 7 的組合〉

取代該行文字的資料

如果只是單純要取代,去掉一行的資料。可以使用 tr 指令,
這樣就不需要使用 sedawk ,花費許多時間在測試正規表示式。

工作上遇到一個需求,需要取出 node.js 專案中 package.json 裡特定模組的名稱,
這裡把需求改為要知道所有的 babel 模組名稱,利用管線,可以串成一行來得到結果。

閱讀全文〈取代該行文字的資料〉

快速截出對應表裡的資料

在實作 CI 流程中,有一段使用 shell script 實作的地方,
需要承接流程開始時傳入的環境變數,由對應表中找到對應的資料,以進行相關的流程。

本來以為需要使用的正規表示式來完成這個功能,但偏偏卡在不知怎麼下搜尋關鍵字,
找到由正規則表示取出某段資料,放到變數裡的程式寫法。
一度在評估是不是要去研究 awk 或 sed 的文件,但又隱隱覺得殺雞不該用牛刀。

好在過了一會兒,讓我找到用更基本指令完成工作的方法。

閱讀全文〈快速截出對應表裡的資料〉