法國的小鄉村，因為人煙稀少所以許多小商店都無法繼續生存下去，在這個名為 Rezay 的小村莊，據說興盛時期曾有八間酒吧與餐廳，當然也有其他的商店和公共設施如學校等，而如今，這裡僅存的小餐廳也在三年前歇業了。

沒有了酒吧的存在，就少了人們可以互相交流的地方，法國人很依靠酒吧搭建起來的人際關係，再加上如果有人聚集的地方，各方的消息與資訊更容易流通，所以小村莊如果有間小酒吧，ㄧ定會促進人們資訊流通的速度，尤其是冬季這裡更是一片死寂，如果有個溫暖的地方，讓人們聚一聚聊些家常，也一定會讓村莊的人們關係更熱絡，進而相互分享與幫忙，尤其這些交流對於老人更為重要。

在 2021 年年初知道村裡有幾位接近退休年齡的居民希望重啟酒吧，但是礙於開間酒吧的成本與費用的考量，實在不是一般人負擔得起的，於是集眾人的力量成立協會，並和村公所以低微的價格租下場地，村中唯一的酒吧得以開始試營運。當時正值疫情嚴重並且封城，既然不移動動，那我們就到鄉下去吧！於是住在巴黎的我們， 2021 年拜疫情所賜，封城時待在鄉下遠距工作。我在春夏交界的時候加入協會，並擔任起所有資訊相關的志工，包括架網站、處理電子報的發送、酒吧的主視覺與臉書粉絲專頁的管理，或是酒吧有活動時需要線上報名的表單都一併處理。

協會的成員有一部份是較於活躍的，也是這群人撐起協會大大小小的事物，且負責酒吧的服務與餐點的準備，有時酒吧也會舉辦藝文活動，例如說書、戲劇表演、音樂演奏或是有主題的聚會。因為大部份的志工都要上班（還沒退休）所以酒吧只有週末的時候會營業，並且由志工輪流輪班當服務生與廚房餐點的準備。關於輪班這件事，原本是使用某個免費的線上服務來調配排班這件事，但是因為那個服務不太穩定，所以討論之下就自告奮勇說要做個排班系統給他們用。

因為會員每一個人使用手幾與網頁的體驗都不太一樣，最無法控制的例如老人也想幫忙，但是不知如何自己報名排班，所以有好幾個月，想輪班的只能在酒吧裡的黑板上填上自己的名字，非常不方便。

原本想說這樣的東西應該用 Google 的表單就可以處理，但是並不是每個人都有 Gmail 帳號，因此使用起來不是很方便便做罷。想說好吧，需要儲存資料，所以再把很久沒碰的 PHP 和 MySql 拿出來碰，但是自己的免費伺服器因為Php版本太低的關係做罷，也有考慮以 firebase 當資料庫，但是研究幾天又被雜事打斷，想說其實不就是讀寫的功能，如果先不要做登入，會不會比較好做？後來還研究到如何把Google Sheet 當成資料庫來用，並且以 HTML 來讀寫。看了一些教學，原來是要在 google app script 裡寫好腳本，再以 get 和 post 的方式將資料引入並顯示。

在研究怎麼寫的期間，也不知怎麼的，撇見了 Google 有個新的服務叫做 AppSheet ，看了一下官方教學影片馬上就來試做，結果不到兩小時就處理好了！驚艷到使用上的方便，且可以自動部屬，就差網址連結沒那麼好看，但是讀寫的功能操作起來也頗順暢的。部屬完成之後寄給同是志工的老鄰居（原本在大學教 C 語言），寄過去沒幾分鐘就收到訊息說好用，並且自己已經上去填了排班表，接著下午寄給負責排班的志工和協會長，傍晚就說可以公佈了！

很神奇的，就這樣完成了卡了一些時間的排班工具，真的超神奇的！今年所訂定的 output 顯化年，就這樣開啟了！

Coding 其實是有招式的，如果招式沒打好，除了效率打折，還會讓其他合作夥伴抱頭燒，所以好的開發習慣有必要好好養成。

此篇來自於「在地上滾的工程師 Nic」的 YouTube 頻道的「提升軟體開發品質! 寫程式的 6 招實用技巧」觀看後的筆記，因為覺得條條建議都很重要，又怕忘記，所以寫個筆記來記錄，希望自己可以把這些好習慣養成。同時也很推薦 Nic 的頻道，很多很受用的經驗分享，對於新手工程師而言，這些經驗是早知道的些好。很值得訂閱觀賞，當然也記得要好好的記住他分享的經驗，對往開發工程師的路上前行的人，一定會有幫助的！

他提到培養寫程式的好習慣有什麼好處？有三大好處：

• 有效提升協做效率
• 增加程式被測試的可能性
• 建立一定的專頁度

通常專案都會有時程的的壓力與要求，一定有時間的壓力，必然會犧牲掉程式碼的品質，但如果程式碼的品質不夠好，接下來就有技術債的問題，然後新的功能越來越難增加，或是增加了，所許要付出的時間會更多。主要是程式碼不只是要會運作，也需要讓其他協做的工程式看得懂，所以如果能夠對自身有「寫好扣」的要求，對自己或是協作者而言，都可省不少力，如果想當一個好工程師，一定要把這些好習慣養成。

以下就是好習慣養成的六招

避免簡寫，使用有意義的命名

除了函式需要有意義的命名外，變數、參數都應該盡量避免使用簡寫，資料本身已經有型別的問題，如果參數、變數名語意不明。也不能直覺的知道是哪種型態的型別。如果寫簡寫，其他人甚至自己都有可能忘記代表其意義，然後還要花時間去猜，去看上下文，很花時間，更有可能猜錯。
多打幾個字不會花你很多時間，少打幾個字，會花掉無法想像的許多時間。

限制傳入參數的數量

因為需求增加，有可能在寫函式時會增加數個參數傳進函式裡處理，但是如果參數過多，很難定義這個函式要處理的邏輯，因為變因多也會很難做測試，讓函式變得複雜，且一次做太多事會很難拆解並降低函式的複用性，所以參數最好不要超過三個，如果超過三個，可試著再拆解出另一支函式，或是用 has 或 Object 的方式，把這些參數包成一個物件，直接傳進去函式。這樣其他人在看這支函式時，比較可以一目了然這支函式所要處理的邏輯與資料。

簡化條件的表達(判斷)式

可以試著把判斷式的結果直接回傳出去，試著避免撰寫多餘的部份。因為需要回傳的是 Boolean 值，只要把符合的條件以判斷的結果直接回傳就可做到。
以下例子是自己用 JS 改寫，可回去看 Nic 的影片例子會更精確。

1
2
3
4
5
6
7
8
9
10
11
12

// 是否有符合騎車資格，回傳值為 Boolean 
function canPersonRideMotorbike(person){
  if(person.age >= 18 && person.has_rider_license){
    return true
  } else {
    return false
  }
}
// 建議寫成這樣：
function canPersonRideMotorbike(person){
  return person.age >= 18 && person.has_rider_license
}

變數定義範圍的限制

盡量讓變數在函式裡面讀取的到就好（區域變數），也就是盡量避免使用全域的變數。現今 ES6 已有限制區域的 let 和 const ，最好棄用全域的 var ，除非變數有全域可存取的需求。
盡可能把一個變數的作用域限制在函式裡，只讓這個函式可以讀取或修改這個變數，在函式使用之後就丟棄此變數，才是比較好的方式。這樣才能避免全域變數污染與程式難以測試的問題。

一支程式只做一件事情

在封裝函式時，函式定義命名必須要和函式所處理的邏輯有一致的行為，不要在同一支函式裡，加入其他要處理的功能，這樣會造成其他工程師在閱讀與理解上，或是呼叫這支函式而造成無法想像的 effect。例如函式處理訂單總價，就不要夾雜打折或其他邏輯。
如果一定要把另一個行為包進去同一支函式裡，可以把函式取名為比較中性的名字，例如 xxxService，明確撰寫函式需要做什麼事、流程或邏輯，讓其他工程師在乎叫這支函式時，很明確知道這支函式的用途。或是，更改函式的命名，同時把兩個功能行為寫進命名裡，但這樣仍不是個好做法。

Early return (提前回傳)

當 if, else 超過兩層以上，會形成多層巢狀，結構會越來越複雜且難以閱讀，尤其要找出對應的條件更是困難。設計多條件判斷的邏輯時，可使用 Early return 技巧，讓程式盡可能提早結束，避免去執行到不該執行的部份，

改寫成 JS 的範例：
技巧：只要遇到不符合條件，就跳出函式這樣就可以讓程式盡可能保持一層的判斷，如果 if 條件有符合再繼續。
這種在相關的 Design pattern 也有提到，例如 fail fast, guard clause（改天找來看）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// 錯誤示範
function returnStuff(argument1, argument2) {
  if(argument1 === true){
    if(argument2 === true){
      let otherValue = getSomeStuff(argument1, argument2)

      if(otherValue === true) return "Stuff"
      else return "Error"
    } else return "Error"
  } else return "Error"
}
// 較理想的寫法
function returnStuff(argument1, argument2) {
  if(argument1 !== true) return "Error"
  if(argument2 !== true) return "Error"

  let otherValue = getSomeStuff(argument1, argument2)

  if(otherValue !== true) return return "Error"
  
  return"Stuff"
}

再次感謝 Nic 提供實用的資訊與技巧，把這樣的習慣養成，應該可以提高可讀性，也可降低殘害合作同伴的可能。

補充：
關於命名，可參考有意義的命名 | Clean Code.

感覺，走在一條看不見盡頭的路上，又有時，偶而會像是看到隧道盡頭的光。

如果，這條路上真的是一條看不見盡頭的路，那麼有其他人一起走在這條路上，是不是比較不悲情？

身處在與台灣飛行需要 13 小時的國度，自身條件又是中年轉職，已經不想再去回頭看當初的決定是否錯誤，雖然知道這個職場上喜歡新鮮的肝，但是也曾被操過的肝是否會有看不見的優勢？

如果自己有耐心的可以在電腦前超過十幾個小時，為了解決一個小問題，是否我應該能有最不值錢的努力獎或入門票？

把自己當成一個實驗體已經有一段時間了，每次沮喪時，總是想到那些實驗的科學家，或是其他努力經過數十載才看到結果的例子，就會想再給自己一次機會。

Q：當初為什麼報名這堂課？
因為校長曾在直播時說：「我陪你們學到會！」這句話讓我紅了眼眶，覺得或許可以再給自己一次機會，所以連續參加 JS 直播、Vue 直播與接下來的切版直播。想說如果有跟上，如果職場不要我，我還可以做些事。

Q：第一週~第八週的學習過程
手沒有髒都不算。
之前已經有自學過 Vue2 但是沒有完成一個完整專案，很難知道自己的技能是否達到業界的技術要求。
對自己的要求是希望每次繳交任務都是 LV3 但越是後面越覺得困難，主要是還是需要參考其他人的程式碼，如果沒有釐清邏輯，會有很大的問題。
尤其是在使用 Props 和 emit 這部份，好幾次畫面拍下來畫圖示意，然後用時忘了再回去看，反反覆覆好幾次。
每次接任務都怕自己做不出來，做出來又非常高興，情緒很像三溫暖。

Q：最大的收獲是？
這就是程式與一起學的魔力。
自己是金魚腦，語法忘的快，概念也是，所以必須一直去查語法，也需要錄影看好幾遍，有時真的會被自己嚇到，不是看過怎麼沒記住！？
每日的練習和每週任務對語法與邏輯的熟悉很有幫助，其實很想要 Kata 但是時間不夠很可惜。
最大的收獲是有讓自己不間斷的訓練各方面。雖然動作還是不夠快，但是持續做習題很重要。

能夠提問也是天堂。
一直不敢提問，但後來想想自己或許無法都看清楚問題，那就容許自己讓其他人來幫忙，可以提問真的是很棒的環境，許多卡好久的部份，都被大家的仙女棒一點出現解答，或是常在提問的時候中途就發現問題點。

Q：最喜歡直播班的哪些活動？
我什麼都要，都喜歡。
每日作業、每週任務、老師，助教的直播、小組討論都有幫助，尤其是每日作業，真的可以讓一些概念理的更清楚。如果有每週測驗，我應該可以更記得注意一點！

Q：如果時光能倒流，會希望自己再次注意哪些細節？
如果時間能倒流，可能會先參加切版直播班、再來是 JS直播班，然後才是 Vue.js 直播班，因為發現在做 Vue 的作業時，調版面好花時間，而且不是自己切的版，所以看準備好的版也蠻吃力的。

一天只有 24 小時，自己是除了睡覺、煮飯、吃飯之外的時間，都在課程，作業和練習上，所以如果能重來，我應該還是會努力跟上。

JS 直播班因為時差不好意思加入小組，後來發現其實小組討論互相鼓勵也很好，Vue 直播有加入小組，果然感受到大家一起互相鼓勵互相學習的作用。

Q：身為學長姐，分享些想入坑的新同學一些勉勵的話

• 有校長的「我陪你們學到會！」這句話，你還在怕什麼！
• 能的話盡量把基礎打好，不然坑要填會更花時間。
• 把自己一天精力最好的時段留給學習，因為大量用腦很容易沒電。

最後，想感謝六角的洧傑校長和卡斯伯老師，還有助教群與同學們的幫忙，還有默默在一旁陪我的老公。

期待自己 可以對程式感到自在
期待自己 可以信心滿滿的做出想要的功能
期待自己 可以對其他人有回饋與幫助
期待這樣的自己，我會繼續努力！

表單在網頁上的應用很頻繁，也是與使用者互動的重要部分，凡舉聯絡的表單，或是資料的填寫、登入，都會用到表單，透過表單所得取的資料，如果不符合格式，也會造成後續資料處理上的麻煩與困難，雖然我們也可以透過 HTML5 來驗證使用者填入的是否符合一些基本的規則，但是無法定義比較細微的部分，這時候就必須自己動手寫驗證了。

好工具哪有不用的道理

如果自己寫過表單的驗證，就會知道其實是很瑣碎的，在邏輯的處理上也必須花些心思，如果能力許可當然可以自己寫一個套件來用，但是套件如果別人寫的又好又完善，也真的可以不需要自己刻。

使用套件的心態或許可以放在：「套件會用就好」，第一時間或許不需要了解原始碼怎麼寫，但一定要遵循官方文件，來理解如何使用，且官網的文件解說與使用說明大都很清楚，也就很容易上手。待有多的時間再來翻看原始碼也不遲。

validate.js 便是一個完善的套件，表單需要的驗證該有的都有，而且引入就可以使用了，那麼就來理解一下，如何使用 validate.js 來驗證表單。

Ajax 的出現，優化了不少使用者體驗，也縮短了網頁顯示的時間，這篇僅單純的淺談什麼是 Ajax 以及應用 Ajax 來做非同步資料請求的方式。

Ajax 全名為 Asynchronous JavaScript and XML，一種允許瀏覽器與伺服器交換資料，而不需刷新頁面的技術，都可以叫做 Ajax.

Ajax 這個名字是在 2005 年 5 月的時候，Adaptive Path 的 Jasse James Garrett 在他所寫的「Ajax : New Approach to Web Application」文章中提出的。而 Ajax 這項技術，是由 Google 在 Google labs 發佈的 Google Maps 和 Google Suggest 後真正為人所認識。

現在的網頁講求的是不只是速度，與使用者之間的互動也非常的重要，這些互動免不了由 JavaScript 的「事件」或「監聽」來操作，而這些操作往往包含了對 HTML 標籤或網頁元素取值，增加元素或屬性來達到效果，這篇主要介紹如何透過 JavaScript 來控制或修改 DOM Tree 上面的節點元素。

DOM 是什麼？

DOM, (Document Object Model, 檔案物件模型)，是網頁內容（HTML 或 XML）所建構網頁的內容結構，並提供給編程語言一套完整的操控檔案文件的 API 。

DOM Tree 樹狀結構與節點(node)：網頁的結構有如樹狀般，這些相連的交會點，有如骨骼的關節，每一個節點上是網頁結構的元素所構成。這些節點(node)具有關連性，也具有父層或兄弟層的關係。分為以下三種：

• HTML 元素節點(element nodes or element objects)
• 文字節點(text node)
• 註解節點(comment node)

DOM 提供了兩種節點的集合：HTML collection(element nodes) 以及 NodeList (包含以上三種)。以下圖來說，如果選擇選取 HTML collection，那只會選取到 Element 的部份，但如果使用 NodeList 的方式，就可以選取指定元素底下所有的節點(NodeList)。

我們常常需要把一些資料裡面的數字相加，但是拿到的資料卻是字串，字串和字串相加，只會讓數字串在一起，並不會計算數字，這時我們會先將字串，轉成數字型別再做運算，最常用的方法就是parseInt()和 Number()。但這兩種有什麼不同呢？

parseInt()

語法：‵parseInt(string, radix);‵

parseInt() 會將指定的字串以指定的進位方式轉換成整數。 parseInt() 可以帶入兩個參數 parseInt（string，radix），第一個參數就是我們希望轉換成數字的「數字字串」，第二個參數為指定的「進位制」，我們一般使用 10 進位制，也有可能會用到其他進位制，如 8 或 16，解析出來的結果也會依進位制不同而轉換。如果沒有給第二參數，則會默認以 10 進位制來轉換數字。

AOS 是個支援因網頁捲軸(scroll)變化的動畫效果套件，可以在 VueJs 的專案直接使用，讓頁面內容或圖片量多需要往下滑動時，內容或圖片會出現以動畫效果出現在頁面上，讓頁面增加一些互動性。

這次重新以 Vus 3 建構自己的個人網站時，就以 AOS 的套件來製作動畫效果，其實這些效果使用 CSS 的 Animation 也是可以達到的，但測試之後發現手刻的 CSS 動畫可能 keyframe 分的不夠細，和 AOS 的動畫相較起來沒那麼順暢，所以才又回來改用 AOS 套件。

官網的展示效果清楚簡單，只要將 AOS 套件引入專案，變可以開始使用了，效果也只要下幾個關鍵字，就可達到不錯的結果。

因為之前的作品頗多，所以個人網站上有很多圖片，使用的主要是這一頁。

最近重新以 Vue3 來建構自己的網站，雖然內容很簡單，也只有幾個頁面而已，但算是第一次從頭跑到尾。在以 VueJs 3 開發，並且部屬到 Github pages 上的過程中，才知道原來使用框架之後的部屬和以往傳統的部署，有很大的不同。原因是 VueJs 透過 Router 的設定，和 webpack 的編譯打包，有許多的細節設定要做，加上部屬到 Github pages 上，最上層的資料夾並不是路徑源頭，所以有時候出現問題會難找出原因(對我而言啦)。

部屬完成後，網頁跑得還蠻順的，每個連結也都很聽話的顯示，唯有在瀏覽器上頭的連結網址框裡按下 enter 鍵時，噹～噹～出現 404 ，也就是找不到這一頁，怎麼回事？

記得初學 JavaScript 的時候，曾經和 42 的同學討論過學程式遇到的一些「抽象」的名詞概念，因為抽象所以難懂，我總是想要以類比的方式來找出一個合理且容易記住的解釋。這位同學本科是唸哲學（發現哲學轉職工程師的還真不少），他的第一個實習就找到了法國頗有名的電商公司。我們討論著 this 但是似乎怎麼解釋也無法清楚的描繪出來，只聽他重複著說著 this 就是 this…。

有些事真的需要「時間」來幫助我們理解，就像有些新認識的朋友，真的沒有相處過不會知道對方的個性，this 也是，寫 code 一陣子或許就會慢慢的、更清晰的去描繪 this 是怎麼回事。

「this」就像英文原意，是個代名詞，但更貼切的說 this 比較像是地方(空間)代名詞，以程式的面向來說也可以說是「物件」的代名詞，或是「執行環境」、「創建環境」或是「呼叫環境」？到底是哪一個，就要看用的是傳統或箭頭函式的寫法，或是…「呼叫」的方式？

我們常會說 this 到底是「指向」誰？那個誰應該就是包圍 this 的那個環境吧？我試著想像，這好像是我們說身體上的「指頭」，如果說手的指頭，那就是手臂；如果說是腳的指頭，就表示腿，這樣說當然只是一個比喻，但小鳥腦的我只能先這樣記著。