以前在當韓翻的時期，每次拿到遊戲內要翻譯的文檔都會是一個excel檔案，然後有Key的欄位，和對應語系名的欄位，我那時還以為只是開發人員管理方便而已，直到自己也成了開發人員，才知道原來那個是為了要轉成套用在遊戲中的翻譯檔的格式。
其實成為前端後，偶爾會有需求需要更改翻譯文檔，原本都是藉由後端產套用的翻譯文檔，不過好一陣子前，內部更新成用Google Sheets API來產翻譯文檔，比起以前更方便，因為不用再透過後端處理，可以直接在本機跑起來確認。因為也想要自己試著實作一次這個方便的用法，所以就把這個實作方式記錄下來了。實作重點事前準備：
在雲端硬碟上，創建一份擺放翻譯內容的google sheet，會需要填入Key值，和翻譯內容，表格內容大致上會呈現如下。
主要的兩個大步驟：
- 於Google Cloud控制台設定服務帳號、產出使用google-sheets的金鑰
- 活用google-spreadsheet，產出用來套用翻譯的json檔案 文科少女寫程式 發表在 痞客邦 留言(0) 人氣(30)
上禮拜日去參加了一個很有趣的社群活動，也是近期內最令我期待的社群活動之一，主要是因為這是一個以女生工程師為主的實體社群活動，身為這個圈子的邊緣菜鳥的我，當然要去參加一波囉！
「當我們同宅一起」這個實體社群活動主要是由ALPHA Camp和The MentorShip曼陀號領航計畫聯合舉辦，是一場AC助教的限定活動，再加上以前一直很想參與曼陀號計畫，所以當知道有這樣的機會，就手刀報名了。 活動參與對象ALPHA Camp助教&The MentorShip 曼陀號領航計畫Data組/Engineering組成員
女生優先參加，當天還是有幾位男性夥伴參與活動內容雖然是工程師實體社群活動，但活動內容主要還是聚焦在認識不同的工程師，以及與其他工程師交流職場經驗、學習經驗等，而不是比較死板板的討論技術。實際活動流程
實際活動流程分為三個部分，分別是「一對一互動」、「四人小組互動」、「分桌主題交流」。
一對一互動
主要就是找一位自己不認識的人聊天、自我介紹，問對方一個小問題，主辦單位有提供問題小紙，可以選擇一提問題來問。雖然這個環節對於內向的我來說，有點小小的尷尬，但卻是我還滿喜歡的環節，因為這樣才能認識很多人。只是時間有限，所以實際上我好像只和五個人講到話，也都是偏向生活化(?)的談話，不過也足以讓身為邊緣人的我踏出舒適圈XD
四人小組互動
四人小組互動只會進行兩輪，其實這個環節我也很喜歡，在這個環節因為人數剛剛好，不會太多也不會太少，所以聊天不會太尷尬，而且也能有更深入的討論，不會只是打打招呼。不過也因為只有兩輪，所以也是很讓人意猶未盡，好想繼續跟大家聊下去。在這個環節中，還意外認識了一位朋友的朋友，而且也是最近加入的Tycia組織的成員，真的覺得超級無敵巧，也覺得好神奇。
分桌主題交流
這是一個主題明確的交流環節，一共有五個主題可以參與討論，在這次的活動中，總共可以進行五輪的主題交流，所以實際上可以參與五種不同的主題討論。主題分別是「職涯經驗&選擇」、「公司文化」、「在職學習」、「下班生活」、「職場生存」。每桌討論一種主題，且有一位桌長帶領大家進行討論，最令我最印象深刻的是「職涯經驗&選擇」和「在職學習」，這兩桌的桌長帶大家討論的節奏很好，也有讓大家都有很深入的討論和交流。「下班生活」主題那桌就是很放鬆的閒聊，真的就是愉快的下班生活感。自己這次沒有參與的主題只有「職場生存」，其實對這個主題也很有興趣，但是只能五擇四，還是只能忍痛捨去它。 文科少女寫程式 發表在 痞客邦 留言(0) 人氣(51)
雖然我是一位前端工程師，但是因為跟主管自告奮勇(?)接觸新東西，所以就踏入了Nginx世(ㄉ一ˋ)界(ㄩˋ)。雖然很多時候，都只是單純地改現有的設定檔案，但是在改的時候，還是得了解現有策略，避免改到不該改的地方，改寫當然也需要對設定方式有一定的了解，又加上這禮拜終於有些東西有點搞懂了，所以就想說來寫一篇這個吧！
這裡就不詳細介紹Nginx是什麼，單純記錄自己在接觸Nginx的過程中，常碰到但又常搞混的一些我自己認為必懂得Nginx設定內容。root當path匹配到對應的location時，會前往「root」+「path」取得要拿的資源。
範例：
location /resource {
root /data-disck/static/;
}
request URL為https://www.test.com/resource/index.html時實際上會前往/data-disk/static/resource/裡面尋找index.html。alias當path匹配到對應的location時，會前往「把匹配到的path替換成alias設定的內容」+「被匹被到的path外，剩下的path內容」取得要拿的資源。
範例：
location /resource {
alias /data-disk/static;
}
request URL為https://www.test.com/resource/index.html時實際上會前往/data-disk/static/尋找index.html。index用來設定默認要取得哪個檔案，如果匹配到的path已經有明確指定要取得哪個檔案，就不會去拿默認要取得的檔案。
範例：
location /resource {
root/data-disk/static;
index index.html;
}
request URL為https://www.test.com/resource/時：會前往data-disk/static/resource尋找被默認要取得的index.htmlrequest URL為https://www.test.com/resource/test.txt時：因為已經有明確指出要拿到test.txt檔案，所以會前往/data-disk/static/resource尋找被默認要取得的test.txtrewrite會重新定向指定的路徑，並前往「root」+「重新定向的path」取得要拿的資源。
使用上主要會有三個參數，寫法會是rewrite 「匹配規則」+ 「重新定向到哪裡」+「指令(非必要參數)」。
範例：
location ~* ^/(.*)/content/(.*) {
root/data-disk/static;
rewrite (?i)^/(.*)/content/(.*)$ /$2;
}
request URL為https://www.test.com/resource/content/newfile時：
會匹配到這個location，並且將"/resource/content/newfile"這個path重新定向為"/data-disk/static/newfile"拿資源。$2的部分，是指第一個參數中，被匹配到的第二的部分，也就是匹配規則中的，第二的(.*)。如果是$1，就是第一個部分。指令部分
主要有四種指令可以使用
last：rewrite後，會重新匹配location，用被rewrite後的path重新匹配。
break：rewrite後，不會再重新執行rewrite，但是會繼續執行location中剩下的非rewrite的設定。
redirect：會返回302臨時重新定向。
permanent：會返回301永久重新定向。try_files會依序查找指定的檔案，找不到檔案會進行內部重新定向到最後一個參數。搭配root使用的話，會去前往「root」 + 「try_files參數路徑」查找檔案。
範例：
location ~* ^/content/(.*) {
root/data-disk/static;
try_files /index.html /test.html;
}
匹配到這個location時，會先去/data-disk/static/找index.html，沒有的話，會接著再去找test.html以上就是目前比較常碰到且容易搞混的Nginx設定內容。
雖然前端大多不太會碰到Nginx這種和伺服器有關的東西，但其實在接觸的過程中，也讓非本科的我，漸漸對於「網路」這一塊多了一點點了解，而不單單只是知道切版、接API。老實說，雖然過程中充滿痛苦，但還是有不少收穫。
好啦 ，打完收工！文科少女寫程式 發表在 痞客邦 留言(0) 人氣(362)
平常都是接觸Vue、React這些CSR的框架，SSR只有透過近期的讀書會稍微了解它的概念，本來以為自己應該差不多理解什麼是SSR了，直到最近要進一步處理nuxt3專案的部屬流程，才發現自己根本沒搞懂啊！這次想說就稍微記錄一下，近期透過規劃nuxt專案部屬流程，所進一步了解到的SSR。從Nuxt3專案的部屬理解SSR什麼是SSR？SSR是Server Side Render的縮寫，用中文來看的話，也就是「伺服器渲染」。有別於「客戶端渲染(CSR)」，HTML的編譯是交由server處理，而不是交由client處理。所以當使用者點進網頁發送request需求後，server會返回完整的HTML內容，而不會像CSR一樣，是一個空白的HTML頁面，需要透過client，才能把頁面內容渲染出來。SSR頁面產生流程使用者對server發送request => 在server端fetch資料 => server產生並回覆完整的HTML =>下載所有JavaScript => 將event Handlers綁定到DOM上(Hydrate) =>Hydrate完成後，使用者就可以和頁面互動(點擊頁面才會有反應)文科少女寫程式 發表在 痞客邦 留言(0) 人氣(143)
在React世界中，useState是一個很基礎的Hook，就跟Vue世界的ref和reactive一樣，所以其實使用概念上真的還算簡單。不過就在我以為我早就懂它的時候，卻還是默默踩到了一些蠢蠢的雷，這才發現原來我根本沒有搞懂它啊！所以我就來記錄一下useState這個看似平凡，但又隱藏一些需要注意的點的Hook了！useState的基本用法
- 呼叫useState hook時，可以帶入當作state初始值的參數。- 呼叫useState hook時，會回傳一個array，array中的第一個元素是state，第二個元素是用來變更這個state的function，可以用解構賦值的方式取用(如第一張圖)。
- 要變更state時，可以取用useState回傳物件中index為1的元素，以上面的例子來說，就是setState，將要變成的值當作參數使用setState就可以變更state，例如：setState(3)，state就會從原本的0變成3。 文科少女寫程式 發表在 痞客邦 留言(2) 人氣(136)
身為一位前端工程師，除了懂得如何切版，以及如何使用前端框架外，了解跟Internet及其他知識也很重要，所以就想說花點時間來惡補一下><
這次先從最近有碰到的DNS和Domain開始看起！什麼是Domain Name？Domain Name簡單來說就是我們在用網址時，會看到的XXX.com的這段文字，例如google.com。Domain Name的結構Domain Name可能會由多個部分組合而成，不同的部分間是以"."區隔，並且閱讀方式並不是我們習慣的由左至右，而是由右至左。文科少女寫程式 發表在 痞客邦 留言(0) 人氣(35)
轉眼間，即將要邁入一年半的前端工程師人生了！沒錯！我還活著！（是說昨天還夢到自己依然是一位遊戲公司的營運PM，準備被公司派去韓國總公司出差呢。但是會夢到這個夢並不是因為我還沒適應現在的生活啦！可能單純只是有點懷念，呵呵。）
今天突然想來寫一篇心情札記文(?)，除了因為即將邁路一年半這個里程碑，也想透過寫文章回顧過去和展望未來，整理一下自己這段期間的思緒。職場生活概況首先，來講講這陣子工作近況。
最近因為公司內部分組，讓前端的業務量分成兩半，而我所屬的組別剛好又是比較不會有新需求的組別，所以近期大多數時間跟前年不太一樣，不是專注於前端相關需求的開發，而是在碰一些完全沒有學過和碰過的CI/CD和nginx，因為我們預計要把前端的部分，從原本混著api內容的大專案中拆出。雖然因為是我沒有碰過的東西，而遇到不少挑戰和挫折，但會有機會碰這部分也是因為在年底面談時，有跟主管提到想要試試看這些新東西。這段期間真的接觸了好多我從來沒仔細認識和思考的知識，主要是HTTP相關的網路與伺服器連接的內容。真的沒想到原來網頁在向伺服器發送request和接收response的這段，有那麼多神奇的操作方式，可以透過path導轉到別的地方，或去不同地方拉取資料。這幾天應該也差不多會把這部分的任務告一段落，不過昨天上到staging上的時候，因為我自己還沒完全理解staging上CI/CD的運作方式，導致出現了一些問題，還好老大出手相救，我當下真的完全慌了，甚至不知道要怎麼查問題點。總結來說，這段期間雖然不斷地燒腦、查資料，並且獲得許多挫折感，但是完成後的成就感也不少，即使這段期間自己認為不算真正理解公司內部完整的nginx的設計，但的確也從中學到了不少東西。
再來說說前端開發業務量減少後，我們主要都在做什麼。
除了近期的這個調整CI/CD和nginx的任務外，還研究了以下這兩個東西：
領域驅動設計(Domain-Driven Design，縮寫DDD)
原本是預計用這個架構來重構前端專案，但在研究和POC過後，發現如果只放在前端專案中，套用DDD的架構，可能會遇到不少問題。而且整體評估的結果是缺點多於優點，所以暫時不考慮以這個方式進行。不過在研究DDD架構和做POC的這段期間，也有一些收穫，除了了解軟體的設計架構外，為了實作POC，也去接觸了一些design pattern。
微前端框架qiankun
微前端這個詞，其實我原本並沒有聽過，也是在這次的研究後才知道什麼是微前端。因為本來專案的某個部分就有要拆出來獨立成另一個專案維護的打算，所以原本是預計用這個框加下去將專案的不同部分組合在一起。不過在研究和POC過後，發現這個框架其實只是一個強化版的iframe，有一些地方雖然比iframe好用很多，但仍然無法滿足我們所有目前的使用情境，所以最後結果一樣是不考慮使用。但也因為去研究這套框架，才讓菜到不行的我認識什麼是iframe。
老實說在研究這兩個新東西的期間，自己當下感受上會覺得有點恐慌，因為感覺就是單純的研究和POC，沒有任何實質的產出，就會覺得自己好像沒有做什麼事情，但回想起來自己獲得的一些知識也許當下沒有辦法有直接的產出，但在日後需要進行重構，或是切分專案以微前端架構進行開發時，應該還是能帶來一些幫助，因為自己的眼界已經被開拓了。文科少女寫程式 發表在 痞客邦 留言(0) 人氣(212)
前陣子有遇到需要在build後，把產出的一些js、img、font檔案加上客製化hash，以避免網頁cache住的調整事項。但是透過file loader來客製產出的檔名hash後，實際上完成build，卻發現每個svg檔案都被重複多build出一份沒有被改成客製hash檔名的檔案，font的檔案還有無法被解析的問題，最後和前輩查了很久，才排除了這個狀況。避免使用file-loader設定時，在build後，產生重複的svg檔案實作情境為了客製化build出來的檔案名，我們需要在vue.config檔案中使用file-loader來設定檔案名稱。這時候會在configureWebpack下的module裡面設定rules(除了svg檔外，還可以依照實際的需求設定其他檔案類型的rule)，設定內容如下。進行yarn build或npm run build之後，會發現build出來的dist資料夾裡面，出現兩個相同，但是名字中的hash不同的檔案。問題發生原因&解決方式為什麼會發生這個問題？會產生兩個相同的檔案，主要是因為build的rule套用到預設的rule和file-loader的rule。預設的rule並沒有被file-loader的rule覆蓋過去，而是兩個rule都被執行了。文科少女寫程式 發表在 痞客邦 留言(0) 人氣(23)
前陣子剛好需要在Vue專案上設定到環境變數，但是卻發現怎麼改都沒有反應，所就又廢廢的寫了這篇小筆記。在Vue專案上設定環境變數實作情境已經用.env檔案設定想要加入的環境變數，卻沒有正確套用這個新增的環境變數。實作方式利用想要在Vue專案裡面設定環境變數，要注意以下幾個地方。1. .env檔案要放在專案根目錄。
2. 環境變數的名稱必須以VUE_APP開頭，例如以下這樣。
VUE_APP_PORT=78784
3. 設定完.env檔案後，需要重新run一次專案。
*這次在設定時，就是沒注意到第一項和第二項才沒有辦法正確
設定完後，就可以在vue檔案中，透過process.env取得設定的環境變數。這裡是透過console.log()印出來的內容，紅框的部分就是透過.env檔設定的環境變數。如果要依照development mode或production mode設定不同環境變數的話，可以透過.env.development或.env.production檔案來設定。貼心小提醒！！因為是亂亂寫筆記，真的就是純紀錄之前實作時，如何解決曾經卡住過的問題，所以主要都是解決問題的方式為主，不會有太多詳細說明。 文科少女寫程式 發表在 痞客邦 留言(0) 人氣(227)
之前偶爾會在公司的專案碰到前人用Rx.js寫的內容，但是天資愚鈍的我幾次自己嘗試去理解Rx.js的概念，都好像通了，又好像沒通。直到前陣子讀書會上，Ken大大分享觀察者模式(Observer Pattern)，這個Rx.js主要運用到的設計模式，才感覺自己應該有比較通了，所以想說這次就試著從上次讀書會中學習到的內容，延伸做一個Rx.js基本概念的學習筆記。觀察者模式(Observer Pattern)是什麼？如果去查相關資料的話，可能會查到類似的說明「observer訂閱observable後，當事件發生，observable就會去通知訂閱這個observable的observer。」
(這不是在繞口令，但看起來很像在繞口令)
雖然這句話，看起來不太難懂，但是對於當初第一次碰到這個pattern的我來說，observer(觀察者)和obervable(可觀察者)這兩個詞其實很抽象。等比較理解了之後，才發現其實沒那麼難。文科少女寫程式 發表在 痞客邦 留言(0) 人氣(93)
打工仔人森 (3)