文科少女學程式

文科少女寫程式 發表在 痞客邦 留言(0) 人氣()

今年很幸運地拿到了一張免費的Modern Web Conference門票 ，所以就請了個假去參加了，以往只參加過假日舉辦的技術研討會，這次是第一次參加在平日舉辦的研討會。也因為以前參加過的經驗，知道不太聰明的自己一定不會馬上就融會貫通，或是馬上學會什麼新東西，所以主要是抱著去聽聽有什麼新知的心態去參加。雖然是以這樣的心態去參加，這次還是想要稍微記錄一下參與的過程中聽到了什麼。主要會分為三個部分，分別是「聽到什麼關鍵字？」、「看到了什麼自己有接觸但還有獲得新知的技術知識？」，以及「在工作坊學到了什麼？」。

(繼續閱讀...)

文科少女寫程式 發表在 痞客邦 留言(0) 人氣()

別以為只要傻傻地一直做就會得到高薪或爬到管理職，想要讓自己的職涯發展得更順利，及早找到自己的定位和方向，朝著目標前進，才能到達自己所想的目的地。
前兩次的月會主題都跟自我成長、學習比較有關係，這次的月會主題則比較不一樣，是跟職涯發展比較有關係的內容，這也是大多數的人會比較迷惘的部分。剛好這週一公司例行的全公司會議上，總經理也有稍微提到「要當躺平族？還是持續努力前進？」，雖然跟月會這個比較明確的主題比，議題範圍又再大一些，不過我覺得每個人還是都很值得好好思考這部分。(不過我想已經躺平的人應該也不會去思考這麼多ＸＤ)
本次月會主題
職涯的進階，該成為 Individual contributor 還是 eng manager？
本次月會流程
這次月會的流程大致上如下：
船長分享 > 中場Q&A > 航海士分享 > workshop > 船長結語
船長分享 - 重點摘要
晉升的形式
說到晉升這件事，或者更攏統一點說「往上爬、往上成長」這件事，最常見的不外乎就是成為管理職、轉職、去海外工作。
對於我來說，其實從以前就一直沒有很想成為主管職，所以都只有在自己的當下的職務中，透過各種任務突破自己，讓自己獲得成就感，直到轉職前的最後一份工作發現自己沒有辦法再向上突破更多了，才選擇轉換到工程師的跑道。
晉升的迷思
這個部分我覺得很有趣，因為真的很多都是大多數人對於「晉升」這兩個字的刻板印象。
- 時候到了就會升職？
「戲棚下站久了就是我的了」這句話大家應該都有聽過，但是如果有一天真的是站久了就是你的了，是不是該去思考這樣自然而然發生的結果，自己是否能有能力承擔及勝任。
- 管理者的錢比較多？
的確在大多數的情況下，管理者的錢會比較多，但是還是必須去思考「所以我是為了錢才想要成為管理職？還是我是覺得自己有能力改變現況才想成為管理職？」成為管理職也許薪水會變多，但是要負擔的責任也更大，自己是真的有能力去承擔嗎？如果只是為了想要有更高的薪水，是不是可以透過其他途徑達到？而不只是一昧地為了錢而成為主管職。
- 到老還是工程師會被淘汰？
很多人可能會擔心年紀大了可能就學不動新東西，比不過年輕人了。但是其實只要自己不是把不同的每一天活得像同一天一樣，即使是年紀大的工程師，還是有他的價值，因為他過往累積的經驗是年輕一輩的人沒有的。其實不只工程師這個工作，其他種類的工作也是一樣的，因為時間累積的經驗，甚至是產業知識，並不是教課書上所可以學到的東西。但是回過頭來思考，如何讓自己能因為年紀而成為職場上更有價值的人才，也是需要自己努力的課題。
- 能不能只寫程式就好？
這應該也是大多數工程師的疑問吧！當然可以只寫程式就好，但是如果要只寫程式就好，那就得想辦法讓自己程式能力達到一定的程度，甚至是發展為專家等級，才不會被市場淘汰。
工程師職涯的兩個方向及方向別的差異
大致上可以區分為兩個方向：
- individual contributor(IC)
專注在技術上，提供技術方面的領導和指導。
- engineering manager(EM)
不以技術為重點，以團隊資源及人與人之間的互動關係為主，負責帶領和管理一個或多個工程團隊。
我自己覺得這兩個方向都是在公司中，比資深還資深的身份，或者是說像普遍大眾理解的管理職身份，不過關注的點有點不同，IC會把心力放在技術為主，EM則偏向把心力放在人的關係上．
也因為如此，他們實際上要做的事情也一些差異。
IC需要做的事情
主要是技術的領導，以及系統、架構面的規劃，以及內部新手的指導，也需要確保公司專案的技術選擇能與公司的目標一致。另外，還需要對新技術保持一定的敏感度，要常常接收一些技術相關新知，也可能會有機會代表公司去外面參與一些研討會的分享。

(繼續閱讀...)

文科少女寫程式 發表在 痞客邦 留言(0) 人氣()

文科少女寫程式 發表在 痞客邦 留言(0) 人氣()

做一份工作，別只是埋頭苦幹把它做完，而是思考該如何把它做對，這樣才有能力成就出自己在市場上最吸睛的亮點和價值。
又到了令人期待的月會時間了，這次的月會內容原本覺得自己因為還太菜，可能無法有太大的收穫，卻意外得還是收穫滿滿！
而且這次的主題也讓我延伸聯想到最近公司內部主管跟大家開會時提到的兩個關於將公司產品成功推銷出去這部分令我印象深刻的內容：
- 想把自家產品順利賣出，最重要的就是要有「有別於市場競品的亮點」。
- 我們家的產品價格的確在市場上偏高，但是並不是我們的產品貴，而是你買不起，因為我們有努力讓產品有值這個價位的品質。
雖然上面這兩段話，主要是在講產品銷售，但仔細想想我們在市場上求職，不也是一種銷售嗎？只是是在推銷自己。
那要怎麼做才能讓自己有能力以高價將自己售出呢？這次月會主題關鍵字「掌握商業價值」，我想就是一個很重要，但是卻常常被忽略的部分！
本次月會主題
工程師能如何學習掌握商業價值，取得更好的職位與薪酬？
本次月會流程

(繼續閱讀...)

文科少女寫程式 發表在 痞客邦 留言(0) 人氣()

mutable和immutable是一個很重要的觀念，而且mutable和immutable其實和JavaScript的基本型別和物件型別的傳值(by value)、傳址(by reference)特型有很大的關聯，我們這就從傳值和傳址的部分開始看吧！
基本型別的傳值特性
所謂傳值(by value)？
「傳值by value」白話一點來說的話，就的是「以值為基準，而不是以址為基準，每個值都是獨立的，就算值看起來是相等的，但所佔的記憶體位置都不同」。
可能單單這樣的一句話，還是很難理解，接下來透過一些實際的情境來理解吧！
實際的程式碼情境

這一段程式碼，做了幾個動作，以行為單位分別是「宣告變數」、「用既有變數來宣告新的變數(將既有變數值賦予新變數)」、「對變數重新賦值」。
宣告變數
var a = 1;
在宣告變數時，一開始會先將變數指向undefined，再進行賦值的動作。JavaScript會留一個記憶體空間給這個值，在這個情境中，以圖呈現的話，會是以下這個樣子。
(1) 一開始會先指向undefined(如果是用let或const宣告的話，這一步的狀況會有點不同，這部分可以參考之前在學習hoisting特性的筆記文)。

(繼續閱讀...)

文科少女寫程式 發表在 痞客邦 留言(0) 人氣()

你是否也只把關注點放在如何解決問題(How)，而沒有再多去想想為什麼要這樣解決(why)？
你是否只關心結果，而忽略過程？
這次很榮幸有機會可以成為曼陀號領航計畫的成員，其實之前早就想要參加，但是在知道曼陀號的時候，剛好自己也還沒有什麼實務經驗，覺得報名可能比較沒有幫助，所以就沒有報名。但是現在的自己已經有一點點經驗，覺得是時候報名看看，就付出行動了，也很幸運地有入選，而且這次的船長又是一位自己一直都覺得很優秀的大大，也就是關鍵評論網集團整合長Richard，真的覺得很開心！
而且第一次月會其實就有好多好多收穫，怕自己忘記自己到底從中吸收到什麼，就來簡單做個心得紀錄吧！
本次月會主題
如何提升專業技能實力？要追求廣度還是深度？
本次月會流程

(繼續閱讀...)

文科少女寫程式 發表在 痞客邦 留言(0) 人氣()

這次碰到的問題其實是一個在任何開發情況下都有可能撞到的問題，仔細想想好像以前也曾撞到過一次，但是自己當時卻沒有那麼深刻的印象，為了避免自己再次撞到，所以想說把它給記錄下來。
排除異常錯誤問題
實作情境
這次是在替換元件的時候，碰到這個問題。我們自己有把包一個元件在專案內做使用，主要是在做emoji-picker的元件替換(這個元件是使用emoji-mart結合material-ui的元件組合成我們專案要的樣子和操作方式)，用舊版的元件不會有問題，但是換成新版的元件卻會跳出錯誤(如下圖)，且點擊後無法顯示應該要顯示的emoji popper。
除錯過程
1. 確認是否是新版元件應該帶入的props沒帶或帶錯。
2. 我這裡還有嘗試先把emoji-picker內的emoji的部分拿掉，替換成一般的文字，發現不會跳錯，popper也可以正常顯示，確認到更emoji-mart有關。
3. 近一步確認emoji-mart使用上有沒有錯誤，還是沒排查確切的問題點。
最終問題排除方式
最後發現原來是版本撞到，舊元件使用的emoji-mart版本是3.X.X，新元件使用的是5.X.X，使用的專案內已經有安裝的emoji-mart版本則為3.X.X，所以在使用舊元件的時候不會有問題，替換成新元件時則出現跳錯和無法開啟的狀況。最後把使用專案內的emoji-mart移除掉，單純使用打包好元件內的emoji-mart，才排除了這個問題。
雖然這次是在替換元件的時候發生，但感覺在其他不同但有點類似的情境中，可能也會撞到這個問題，所以當該檢查的方向都檢查過確認無誤時，也許可以往版本是否有衝突的方向下去排查。
貼心小提醒！！
因為是亂亂寫筆記，真的就是純紀錄之前實作時，如何解決曾經卡住過的問題，所以主要都是解決問題的方式為主，不會有太多詳細說明。

(繼續閱讀...)

文科少女寫程式 發表在 痞客邦 留言(0) 人氣()

最近終於有新專案可以碰了，但是碰新專案之前，會需要經歷幾個步驟，要先install在把專案run起來，有時候就有可能會遇到node-sass版本不對的問題。
排除node-sass版本不符問題
實作情境
在clone新專案後，正常的進行install程序後，要把專案跑起來時跳以下的錯誤。(已經切換到應該要使用的node版本，仍然會跳錯)
問題解決方式
可以透過以下方排除這個狀況。
1. 確認已經切換到該使用的node版本。
2. 切換到node module資料夾李。
3. 透過以下指令讓node-sass重新rebuild
npm rebuild node-sass
4. 跳出以下內容時，就代表有順利完成這個動作。
貼心小提醒！！
因為是亂亂寫筆記，真的就是純紀錄之前實作時，如何解決曾經卡住過的問題，所以主要都是解決問題的方式為主，不會有太多詳細說明。

(繼續閱讀...)

文科少女寫程式 發表在 痞客邦 留言(0) 人氣()

前陣子突然被問到，「你說你有碰過Nginx，那你知道什麼是Nginx嗎？」，這麼突然被一問，老實說我只回的出「它是一個伺服器」，如果要往更細節的問，我其實真的就回答不好了QQ
既然發現到自己好像對碰過的東西有些模糊地帶，不如就花點時間，把模糊的地方給清晰化(?)吧！
什麼是Nginx？
Nginx是一種web server，除了Nginx外，還有一個也很有名的web server叫做Apache，不過今天的主角是Nginx，就只以Nginx為主了。
接下來直接看一下官方的介紹吧！
官方的介紹：
nginxX是一個HTTP和反向代理伺服器，也是一個信件代理伺服器，以及一個通用的TCP/UDP代理伺服器。
更白話的去理解什麼是Nginx的話，就是一台當我們連進網頁時，接收我們request，再發送response給我們的機器，那台機器裡面會存放一些網頁的資料(例如：前端相關的靜態資源)，也會有其他附加的用途可以應用。
Nginx的用途有哪些？
大概了解Nginx是什麼之後，再更進一步來看看幾個Nginx比較常會拿來應用的用途。
反向代理
在剛接觸Nginx的時候，第一個接觸到的概念就是proxy(代理)，其中又區分成反向代理和正向代理。
在使用Nginx時，可以透過proxy_pass來設定反向代理，接著也來快速看一下反向代理和正向代理的概念各是什麼。

- 正向代理：
在正向代理的情境下，當client，也就是我們使用瀏覽器輸入網址，發送request的時候，會先連到proxy server，再轉連到我實際上真正要連到的web server。這個時候真正的目的地並不會知道更早之前發生什麼事，都只知道proxy server對他發送request，所以會不知道實際發送request的人是client，而不是proxy serve。這個情境通常都會應用在VPN上，沒錯！就是大家最近常聽到的surfshark VPN的VPN，有在玩遊戲或是跨到國外追劇的人應該都對這種VPN不陌生，而他的應用概念就是正向代理，白話一點來說的話，也就是先連到VPN提供的proxy，再用那個proxy去騙實際上要連到的目的地你的真實身份，因為他只會知道是VPN的proxy對他發送request。
- 反向代理：
正向代理隱藏的是client的身份，那反過來看的話，反向代理也就是隱藏真實目的地。在反向代理的情境下，client端，也就是我們使用瀏覽器輸入網址，發送request時，我們會以為proxy server是我們的目的地，但是實際上proxy server還會繼續往下導到真正的目的地。這個概念的應用情境通常都會應用在負載平衡上和與安全相關的防火牆上。
負載平衡
這邊應用到的概念也就是前面有提到的反向代理，透過設定upstream 搭配 proxy_pass來達成。當負載太高時，就會被分配連到其他伺服器。口語化來解說的話，也就是雖然連的網址是一樣的，但會依照當下的負載狀況，去分配實際上連到的伺服器．
緩存
Nginx還可以拿來做一些緩存的動作，可以透過設定proxy_cache來進行緩存的動作，如果是已經有取得過的資源，就不會再重新拉一次資料。
靜態HTTP伺服器
如果有一些靜態資源，也可以放到Nginx裡面，透過發送指定的request，下去取得要的資源。這個也是我之前實務上有用過的用法，前端的一些靜態資源會被放到指定的Nginx裡面，當request path有對到對應的設定，就會到指定的位置取得靜態資源。
總結
Nginx是一個伺服器，但不只單純可以接收request和發送response的伺服器，還附帶多種用途可以應用，也是因為這樣，有很多人在使用Nginx。我自己碰過的寫法是用consul template下去寫，但這篇單純簡單地認識Nginx的部分，就不談詳細的內容怎麼寫了。
最後再來個接觸Nginx的心得總結！雖然自己目前還不是什麼Nginx專家，但是前端如果有去了解這部分，的確對於開發業務上有一定的幫助，也比較知道在發送request和接收response的這個過程，到底都發生了什麼事情。而且等到有理解到一些部分後，腦海中就比較好把這些偏抽象的概念轉成畫面。所以如果跟我一樣原本只專注在純前端的技術，對於偏向伺服器的這部分內容不是很了解的朋友們，就非常推薦去玩玩看Nginx，一定能讓打開自己的視野喔！XD
好啦！這次小小的學習筆記就到這裡囉！掰掰～

(繼續閱讀...)

文科少女寫程式 發表在 痞客邦 留言(0) 人氣()

這幾天接受了白板題的小測驗，解了一道題，其中提出這題測驗題的大大也分享了他的解法，回到家後，自己也嘗試了一下他給的更好的解法，這邊也來稍微紀錄一下。
首先，一樣先看題目內容
題目需求
從陣列中取出加總起來的合可以等於第二個參數的兩個數字，並返回它們在陣列中的index。
解題過程
在現場我想到的方向如下：
第一個方向 - 先排序陣列，讓他可以從小至大排列，用兩個個pointer，一個從頭開始移動，一個從尾開始移動+ 迴圈來檢查哪兩個數字的總合等於第二個參數。
但是！！回家重新復盤檢討後，才發現這麼做並不是正解！！
發現到的問題是「因為我有重新排序，所以出來的index會是錯的。」
雖然這個做法的確可以找出可以加總出正解的兩個數字，但是最終回傳的index並不是正確的。
我自己檢討的時候還有針對這個方向做修改，修改方式就是複製出一個陣列做排序。
但是！！這樣做還是有問題，因為如果陣列內對應到正確整合的兩個數字是同一個數字的話，用indexOf回找數字的index只會找到排序第一的數字，也就無法return出正確的答案。
第二個方向 - 不做排序，透過數字差下去找另一個數字的位置。
這個方式是當天出題大大給我一些小提示後，又想到的方式，但是因為一樣有用indexOf去找數字的index，所以一樣會有方向一檢討後調整解法的問題。
第三個方向 - 效率比較差的雙迴圈的方式。
這是另一個我自己在家檢討的時候，想到的方式。雖然因為跑了兩個迴圈，時間複雜度變成O(n^2)了，整體效率比較差，但至少有先達成這道題的目標答案。
外圈從頭開始跑迴圈到倒數第二個數字，內圈從第二個數字跑到最後一個數字。
第四個方向 - 只跑一次迴圈，並且用查找效率較好的物件儲存扣掉當前遍歷到數字後，還剩餘多少的數字和當前遍歷到的數字index。
詳細把程式碼實作出來後，只需要跑一個迴圈，整體效率比較好，且可以達到這題需求的解法其實還是當天出題大大最後提點我的解法。
這裡也將完整的程式碼實作出來如下：
每個小步驟的說明
1. 準備一個拿來存[target - 當前遍歷數字]剩餘數值和當前遍歷數字index的空物件。
2. 跑一個for迴圈，每跑一次都會去計算遍歷到的當前數值還差多少可以達到target數字。
3. 如果temp裡面沒有對應到的剩餘數值的話，意即如果去查找temp物件，返回undefined的話，就把當前數字差多少的數值和當前數字的index放進temp物件裡面。
4. 如果從temp中查有查找到對應的剩餘數值，而且存儲數字的index和當前跑到的數字index不相同的話(因為不能自己跟自己加總)，就返回自己的index，儲存當時數字的index。
這樣就完成了！感謝那位大大當天最後的提點，讓我學到一個很不錯的解法。
 

(繼續閱讀...)

文科少女寫程式 發表在 痞客邦 留言(0) 人氣()

自己平常在寫Vue的時候，其實很常會使用到computed。因為當自己只是要一個被處理過後的值，在它被處理的過程中，又有一些相依的值時，就會使用computed。正確使用的話，不僅比較能節省效能，在程式碼的閱讀上，也更能一目瞭然地看到整體邏輯。因為實在是很愛使用computed(?)，在碰React的時候，也在想是不是在這樣對應的情境中，也能有類似computed效果的東東可以用？沒想到真的有耶！那個東東就是useMemo。
在進入今天的正題－useMemo之前，先來回顧一下Vue世界的computed。
Vue 的 computed
使用方法(以Vue3為主)
- 單純使用get：當有相依的變數有變動時，就會重新計算最後的結果值。但若相依的變數沒有改變，就不會重新計算。
*這裡還有一個重點是「這個值如果沒有使用在template上或其他的邏輯中，即使相依的值有變動，也不會重新計算」。

- 搭配set做使用：變動計算後的值時(例如範例的full name)，會觸發setter，若沒有設定setter，直接對計算後的值進行變更，會跳出錯誤(this._setter is not a function)。
需要直接操作到計算後的值時，就需要把set的部份加上，如下範例。

React的useMemo
使用方法
可以帶入兩個參數，第一個參數是一個寫著計算內容的callback funtcion，第二的參數則是一個陣列，可以內含有相依的變數。

當沒有帶入第二個參數時，不管實際相依的參數有無變動，每次渲染時，都會重新跑一次useMemo，重新進行一次計算內容去產生新的值。
當帶入的第二個參數為空陣列時，則只會在第一次整個DOM渲染完成時跑一次計算產生出值，並記錄下這個值。
當第二的參數的陣列中，有帶入值時，在整個DOM渲染完成後跑一次計算產生值後，只會在這些陣列裡的值有變動時，才會再次重新計算並產生新的值。
*與Vue不一樣的地方是「就算useMemo計算後的值沒有用在畫面上，也沒有被使用在其他邏輯中，只要第二的陣列參數裡的值有變動，一樣會進行重新計算的動作」。
關於computed & useMemo的優點&缺點
優點
- 避免不必要的重新渲染
有別於一般的function，不會在每次畫面重新渲染時都重跑一次對應的function，只會在相依的值有改變時，才重新進行計算，也就能減少不必要的重新渲染。
- 避免太複雜的邏輯在不必要的狀況下重新計算
缺點
- 使用時需要注意相依值，才能真正避免重複被計算太多次。
- 過度使用或使用不當，反而有可能會造成效能問題。
總結
最後也來個不專業比較圖做個總結吧！

雖然在Vue世界和React世界中，實務上對於這兩個類似的用法的使用情境應該會有些許差異，但某些程度上，這兩個用法使用的目的上還是有雷同。當有合適的情境出現時，就可以考慮要不要用這個方法。
好啦！這次的學習紀錄就到這裡啦！
(如果有誤解的部分，都歡迎跟我說)
打完收工！

(繼續閱讀...)

文科少女寫程式 發表在 痞客邦 留言(0) 人氣()