小說背景設定-16

Date: 20180809
Version: 1

本篇為前篇「小說背景設定-12」之延伸。

但參考資料做了一些改變，採用教育部國語辭典公眾授權網中的《成語典》，跟上次資料不同的是，該網站提供了成語相關資料的下載，幫助我們更容易了解成語的來源與用法，降低了查找資料的時間。

首先介紹資料格式，相關欄位有編號、成語、注音、漢語拼音、釋義、典源、典故說明、書證、用法說明、近義、反義、辨識、參考語詞，共13項，針對主題進行篩選，不需要注音和漢語注音，典源與典故說明衝突，僅保留典故說明，書證內容不太需要，用法說明與釋義衝突，僅保留釋義，辨識為其他html檔案，不考慮，參考語詞為其他組成之成語，大多數皆不常使用，故最後僅保留6項，另外，為了加入成語能力的解析，故再加上兩個欄位「形」和「義」(文後再解釋)，所以結果一共為8項。

該資料表共有5106筆，刪除大多數可義參的成語後，最後成語總數為1568筆，以上這些列述和欄位就是之後成語資料庫的組成。

接下來就是介紹如何使用這個成語資料庫，為了可以隨時隨地查看/更新成語資料，故作成一個APP是一個不錯的點子，而我使用的還是App Inventor 2，而之前常使用的資料庫，google的spreadsheet，只能讀取無法寫入，故這次選用了其他線上資料庫來儲存資料，有tinywebdb和Firebase兩種，上網查了一下，就決定使用Firebase，主要是因為操作簡單，不需要太多額外設定就可以達成，建立好Firebase相關資料後，就要開始匯入，Firebase使用的是json格式資料匯入，故需要將上述成語資料庫轉換成json格式後再上傳，請注意json格式編碼請使用utf-8，否則資料無法上傳。

Firebase json 格式如下：

有興趣的可以上網查一下，Firebase 的資料庫格視為NoSQL，主要是透過Key-Value進行配對，主要是使用物件來進行建置，當然用陣列也是可以。

前置作業完成後，接下來就是使用App Inventor 2 來製作成語APP了，中間過程就不贅述，直接放結果圖如下：

左1是點擊"GO!!"後，會隨機選去一組成語秀出，點擊"釋義、典故、近義、反義"後，會出現左2，會顯示其內容，如果長按"GO!!"的話，會出現左3，可輸入成語的編號，目前有填入相關資訊的是左4，分別在"形"和"義"鍵入相關資訊後，按下"儲存"，即可將內容上傳到Firebase。

開發的過程中，花最久的時間反而是在版型的建置上，一開始是用下拉式選單，但發現效果不太好，形和義，本來是當選擇某一個另一個textbox會隱藏，但發現不太好用，最後就改成兩欄式，兩邊可以一起對照的打，再來說明一下的是，在讀取資料的時候，一開始設計是將該組成語所有資訊讀取下來後，在程式內進行檢索，但發現在某些編號的成語，會出現讀取錯誤，我也找不出原因來，最後，就改為每一個按鈕的是去跟Firebase進行讀取，這樣處理後，就沒有再發生讀取錯誤的問題了，再來就是Firebase(免費)有限制每月10GB的下載量，目前看起來很夠用了。

以上就是成語APP的製作過程，接下來就開始進入到正題，也就是本次小說背景設定的設定了。

這篇主要的就是形和義兩種，所謂的義，就是成語的真正意涵，而形則是就字面解釋成語，例如：「三人成虎」，並不是只有三個人變成虎，而是指...等，所以三個人變成虎就是形，而...則是義，也就是說在APP中，要將成語以這兩種角度來詮釋成語能力，希望有一天我可以完成全部1568筆成語的能力詮釋。

另外，該成語的能力也可修成反義，只不過就像法師一樣使用超魔技巧，需要多耗費一樣，使用者也需要提供更多能量。

20180902更新：

在後來使用上發現一點不太好用，就是如果對某個成語有靈感時，但以目前設計是無法找出那個成語的，因為是用隨機取號的方式，所以這次對程式進行了修正，增加了ListPicker的功能，可以在輸入編號的地方，也可以輸入關鍵字，之後程式會用關鍵字搜尋並用ListPicker將搜尋結果顯示出來，讓使用者進行挑選。

只增加了對輸入進行檢核，若是數字，則將該編號相對應的成語拉出，若不是數字，則比對所有成語，將含到該關鍵字的成語列出在ListPicker中，讓使用者挑選，完成後使用起來感覺還不錯。

參考文獻：
1. 教育部國語辭典公眾授權網

霹靂藝術科幻特展
時間: 0629-0924
地點: 中正紀念堂1展廳

Date: 20180818
Version: 1

霹靂第一次展覽，我是和學長一起去的，我看的布袋戲不多，但還是覺得霹靂可以做成這樣真的很厲害，甚至跟日本合作出了「東離劍遊記」。

今年是霹靂第二次展出了，所以我也準備要前往了，可惜的是學長遠居美國，今年沒辦法一起去了。

因此我就跟我妹去看了展覽，早上去看了大英博物館的，下午再看霹靂藝術科幻特展，比較遺憾的是，現場某個時間點有cosplay，可惜都錯過沒拍到照片。

這次比較特別的是，會需要下載APP來進行展場活動，掃描光碼，比較舊的手機沒辦法掃描光碼，就只能掃描QR Code，但這樣說真的，後續體驗就稍差了。

光碼的用途，是提供掃描各個人偶後，會提供該腳色的相關介紹，我認為主要的目的是，增加對各個人偶的認識，以及加深與展場的互動性，畢竟整場如果只是和人偶拍照，說實在的真的會很乾，就像第一次展覽，不是說第一次展覽不好，畢竟第一次本身就是亮點，其實不需要多太多其他的東西，而且也是因為第一次，沒有辦法預期民眾的接受度如何，當然也不會再增加成本。

有了這互動性，大家被留在場內的時間會明顯變長，但要說明的是，現場工作人員其實說明得很詳細，只說要對著人偶掃描，但其實是對著照向人偶的光線掃描，要讓攝像頭對著照向人偶的光線掃描，這樣才能掃描的到，被這個搞了超久的，最後抓到訣竅，馬上就掃到了，另外一個重點就是如果要保留相關內容，就不能刪除APP，另外場內有一區是掃描光碼獲得招式，有機會獲得折價券，有95%和90%，我只抽到95%的。

整場下來，我覺得比第一次好玩多了，互動性高，會讓人有再收集東西的感覺，我妹就玩得不亦樂乎，越是蒐集，就越不甘心有些沒蒐集到，人偶比第一次還要多，連場外都有大型Q版人偶，非常好玩，場內快結束時，有一個小型電影院，可以看到很久以前和現在的畫質，真的差超多的，另外片中還有一個爆點就是「素還真 2020 決戰 大螢幕」，如果真的出的話，一定支持，而且會找學長一起去看，希望那時候他有回國。

最後當然就是販賣店了，有超多公仔可以買，可惜沒錢，最後只買了兩個原聲帶，因為是清庫存，每份只要30元，還送許多明信片，到時候拿來當禮物送人吧。

整體下來，非常期待下次展覽又會有甚麼新花樣，以及2020的電影版，而且聽說「東離劍遊記2」也要出了，真的是非常期待！

有想看到現場照片的，可點擊下方連結進行下載，不確定甚麼時候會刪除檔案，不回補檔。
展覽照片下載

人類大歷史：也受到扮演上帝
                                        哈拉瑞

Date: 20180809
Version: 1

介紹人類歷史

人類歷史科普書籍

總體而言，是從古到今的介紹人類的歷史，每一小節都是在人類歷史中的一部份，所以讀起來不會很吃力，就像看一小篇一小篇的文章一樣，輕鬆有趣。

故事的發展，從物理、化學、哲學、文化、科學...等都與人類的歷史演進有關，讀者都可以從其中找到自己感興趣的一塊，其中，最讓我感興趣的是介紹金錢，金錢是建立在人類彼此之間「信任」，這是我從來沒想過的一點，再更進一步，金錢建立了經濟，或者是說「信任」建立了經濟，建立在彼此對於未來的展望。

因此，如果人們對於未來充滿前景，就會不斷地刺激經濟，反之，若對未來不看好，則經濟趨於萎縮。也由於經濟建立在信任之上，對於未來充滿著前景，經濟就像吹泡泡一樣，不斷地變大，直到有一天出現了戳破泡泡的那個針時，整個經濟就會垮了。

那為什麼經濟會不斷膨脹呢？考慮到經濟也是一種資訊集合體，也會帶有熵的特徵，整體而言，熵是會不斷地增加，不斷降低彼此的連結性，最後導致個體彼此分離，換句話說，這個泡泡遲早有一天會破掉的。

桃捷資訊組二三事

Date: 20180809
Version: 1

從去年12月到現在，我待在資訊組也超過半年以上，不久也將滿一年了，時間過得很快，事情做了許多，就來說說我這段時間的感想吧!!

在資訊組的前幾個月，都沒接觸甚麼程式，因為那時候人太少，每個人都接了一堆業務要進行，主要都是在開會及處理採購案，也都是等到這是上軌道之後，才慢慢地比較多的時間放在寫程式上。

在這段時間中，也發現與其他人溝通佔了業務上很重的百分比，如何有效的溝通，並且留給對方正面的形象，這真的很重要，己以善待人，人以善待己，尊重是互相的，這從我接了別人的業務後有的感慨，當然也不是說是前人的錯，只是每個人的行事作風不一樣，產生的效果也不太一樣。

在職場中，講別人怎樣怎樣是再平常不過的事了，但真的要與對方接觸，你才會知道實際狀況是怎樣，像我接手的案子，前人說誰誰誰怎樣怎樣，但實際與對方接觸過，我覺得對方是很認真的，並沒有想像中的那樣，所以許多事情都還是要眼見為憑。

當然在職場上，也不是一帆風順，也會遇到某些人，某些單位就是很難配合，或是態度強烈，這真的只能靠主管來幫忙，所以有沒有主管是很重要的事，有沒有好主管也是很重要的事。

配合公司政策，每月要回去司機員溫故訓一次，我覺得沒有甚麼不好，偶爾換換工作環境，放下手邊的事情，是可以稍稍放鬆一下，所以個人對於此政策保持正面的評價。

當然很多事情，最後還是會回到政治因素上，對於桃捷這種公營機關，更是如此，當然我們無法改變甚麼，就只能盡量配合公司政策執行。

在這段期間，我也算是蠻適應這種生活了，也知道當開會時，大家都不太會主動參與，這時候主席/主辦人就很重要，至少你要有對於未來的一定規劃，並在會議提出後，再請其他同仁發表意見，這會比甚麼都沒有就要開會，容易進行多了。

所以我認為如果想在桃捷繼續待下去，內部招考轉經管人員是一個不錯的選擇，畢竟輪班人員真的是非常的辛苦啊，我就是因為受不了夜班生活，才想趕快離開，也很幸運的內部招考面試上經管人員，而且也算是有一定的了解的工作，至少我還會繼續做下去。

說到這個，我妹就一直想離職，而不是換別的單位，這我也沒辦法阻止啊，如果年底有調整職位的話，或許明年會考慮搬出去住，畢竟通勤40分鐘實在太累了，希望可以找20分鐘以內都算合適了，大概會以中央為考慮吧。

待了這段時間，也經手許多採購案，這時候你就會發現，有些人明明做得比自己久，但為什麼事情處理起來會是這個樣子呢？真是令人不解，或許這就是古人所說的，以人為鏡，可以明得失的道理吧！當然這也是提醒我們自已不要也變成像文中的鏡子一樣。

從叢林到文明，人類身體的演化和疾病的產生
                                                       丹尼爾‧李伯曼

Date: 20180527
Version: 1

這裡想討論人類是否會演化或者是說進化呢？
第一點，時間刻度不一樣，要進行演化所需要的時間刻度遠遠大於現有人類的生活史，以至於無法反應出演化的事實。
第二點，在於演化是指在足夠多的變異之下，由大自然(環境)篩選出適合生存的一種結果，而變異並無好壞之分，只有適不適合而已，在這個情況下，有兩組變異數可以討論，分為外部變異數與內部變異數，而兩者數值都會很大，將兩者相乘後也就是演化的難易度，可見演化是具有一定的難度。
先說外部變異數，也就是大自然(環境)這一項，利用環境來進行篩選，但人類走向外部改變來適應環境，因此，人類不會因為冷就演化出皮厚毛多的物種，而是產生保暖的衣物來禦寒，因此外部變異數就會相對地減少許多，環境將不再是影響人類演化的變異數。
再來是內部變異數，又可以分成兩數相乘，一是基數，二是變異率，如果基數小但變異率高的話，相乘還是可以得到高變異數，若基數大而變異率低的話，還是可以得到高的變異數，先講基數，也就是人口數，在演化的條件下，在選擇下可以生存且可以產生後代的才算做是基數，目前估測為性成熟且有工作能力，約為20歲，而工作可以到65歲，65歲加上產生後代20歲為85歲，但65歲後無穩定收入，故可能無法生存，往前推算20歲為45歲，因此基數人口為20-45歲，而根據世界人口金字塔推算，從1950年到2100年，此基數人口不斷下降。再來是變異率，基本上會維持一個相對穩定的變異率，會有一個相對穩定的週期波型函數來代表，為固定不變的係數，因此，內部變異數為一個下降相乘一個固定係數，總的來說為下降。
綜合來說，外部與內部變異數皆為下降，兩者相乘後會更小，由此可得出對於現階段人類的演化(進化)是很難看到的。

這本書花了我許多時間，中間發生太多事情了，而且下班後還要看一些資訊的書籍，真的是忙不過來，不過這本書對於了解生物相關的人來說，前六章是可以直接跳過的，對我來說前六章都是在介紹演化在人類身上的演進為何？而這本書真正的目的要從第七章才開始，而本篇的重點在於演化失調，簡單來說就是，文化的演化速度快過人類的演化速度，為何不說環境呢？因為文化是人類與環境之間的交互作用的結果，並不只是單單環境可以決定的，是各種因素下產生的結果，即是文化，而文化演化的速度遠超過人體演化的速度，造成人類的身體無法承擔文化演化的結果，即造成現代各種相關疾病的產生，而綜觀整本書，作者最常提到的解決方式就是，適度運度與適量飲食，一樣是老話重談，但卻是至理名言，看完這本書真的是有起到警惕的作用，要隨時注意自己的運動與飲食習慣。

排班管理系統

Date: 20180415
Version: 1

用來取代副段人工排班可能造成同仁認為副段可能偏好某些人，那些人可以排到比較好的假或是比較好的班，造成人為因素的影響，故此排班管理系統其目的是為了公平公正公開而設計的。

剛好，今年的新人軟體開發訓練課程，剛好有機會請老師提供協助製作這樣的系統，雖然工作繁忙，沒有太多的時間可以進行開發，但可以先和其中一位新人一樣，先進行流程圖之規劃，並請老師提供建議，再加上本身是司機員，對於流程有一定程度的了解。

經過思考後，發現其實排班管理系統，有很大的部分很接近大學常用的選課系統，非常的類似，完全可以使用選課系統的邏輯，再加上車班實際運作的邏輯來完成這個系統流程設計。

資料庫
演算法
前台(司機員、副段)
後台(資訊管理者)

我對於如何製作這樣的系統很感興趣，而且還可以讓我多學一點東西，目前課程使用的是ASP.NET，我一點都不了解，希望有機會學到，但身上事情真的很多，希望之後可以少一點事情，讓我多專心於軟體開發上，除了排班管理系統，還有司機員班表APP要進行。

使用者(司機員)
審核者(副段)
管理者(資訊組)??

排班
交換
審核
公布

資料庫
演算法
前台(司機員)
前台(副段)
後台(資訊管理者)??

1070416今日完成流程圖，之後參考相關文件後，會試著作作看ER Model。

1070417已經利用流程圖的概念做了初版的ER圖，之後要將各實體彙整起來。

1070418今日已經將ER總表完成，等星期五與講師討論。

桃捷公司內部招考

Date: 20171121
Version: 1

公司於九月時發佈了內部招考的消息，共有21個缺，一人最多報名兩個，使用面試的方式進行，一開始我看了招考的缺，想想我應該都不會上，也就沒有太在意，後來聽了學長說，面試就是看臉緣的，順眼就錄取了，而且報名又不用錢，不報白不報，那就報吧！

後來我選擇了企劃資訊組和人資兩個報名，資訊是因為我稍微會一些資訊的，而人資就單純是湊數的，聽我妹說人資的步調都比較慢，到了十月，面試通知來了，時間都是在十月，為什麼要特別強調十月呢？因為我十月是夜班啊！一個在早上，一個在下午，還好是不同天，不然我真是頭大。

先是人資的，我剛到時就發現有一堆人在外面等了，看來人資沒有門檻，所以有一堆人來，一開始我進去就先示弱，說我夜班剛下班精神不佳，之後就是一些面試的相關問題，另外我發現在場的所有人都沒有準備履歷，我有特地準備一下我的履歷，並更新了一下，確實有履歷的話，印像會比較好，因為有人資的主管在，他也說會幫我問問另一個職缺是否須要我，那個職缺是票務中心處理資訊的，不過要求比較高，要工程員或副段以上的人才能投，最後公告出來是從缺，好像沒有人來報名吧！

第二個是資訊組的，在一個小房間裡面試，一開始很直接地問最近寫過程式是什麼時後，我就回答這幾個禮拜內，因為我有在寫手機APP，我就開始展示我的APP給主管看，稍微介紹一下我的APP的功能，之後主管問了一些資訊相關的問題，我都不知道，畢竟我是生物資訊出來的不太了解資訊相關，之後主管也請我介紹一下生物資訊，我就提了一下NGS，之後問了生涯規劃，因為有很多人面試上後，因為考上其他更好的就離職，我就說如果可以有一份正常班的工作，我很樂意繼續待下去。

之後，11月放榜，我考上了資訊組，於12月1日報到，一堆學長姐跟我恭喜高升，不過其實是平調，薪水沒有升，不過大家都對可以在行政大樓工作感到嚮往，不用輪班就非常好了，也發通知制服要繳回，我也是問號滿頭？司機員的制服都是量身定制的，收回到底要幹麻？我問了學姐，學姐說就寫遺失填切結書就可以保留了。

11月是我最後一個月當司機了，雖然新工作一樣有三個月的考核，而且這算是我的第二份工作，還是我完全沒作過的，希望到時後可以一切順利，不用再輪班了，因為司機員的關係，我還有一天的國定假日還沒放，到時後去新單位再放，順便問問如果不忙的話，是不是兩天的特休也可以一起放，就可以12/27，28，29連放，再加上跨年的三天，就可以連放六天了，爽，不過還是要先問問主管。

接著，看看這期招考的結果，共21個缺，錄取了18名，我的工號是1200多號，前方還有30幾位的站務員，大概1250號後都是106期的新人，結果18名中只有3位是106期的新人，比例為16%左右，說明了新人想要考上真的有點難度，但也不是完全沒有機會，因為公司人員流動率算高，所以各部門都會有人離職，所以人員的調動上就會顯得有點頻繁，所以新人也還是有機會的，另外，最近也收到運務處的通知說要內部升遷，兩名都是行控的，而且薪水有一個不變，一個調降，至少資訊的薪水不變，感覺好一點。

前天又收到人資的第三次內部招考了，不過只有一個缺，人資的缺，真不知道為什麼上次不一起招呢？這效率真的是沒話說。另外，最近通過預計明年實施，就是特補休新制上路，為了鼓勵員工放特休，放越多天就會領到越多補助，而補休則是如果沒放完可以換成加班費，以上都是比照北高捷的做法，如此可見之前有多難過，不過也不能這麼說，畢竟桃捷今年才開始賺錢，所以明年開始有獎勵也還算不錯啦，但不知道是不是成立工會的後續影響，就讓我們繼續看下去吧！

之後等到了那邊，工作後再來寫那邊的工作到底是什麼？

工作一個禮拜了，其實也沒甚麼事，就做做一些雜事而已，被叫去參加教育訓練，其他都不算甚麼正式的事，等之後有正式的事再來寫吧。

12月到現在3月，也過了3個月試用期了，我覺得跟司機員的生活實在是南轅北轍的生活啊！可以說是非常的忙碌到爆，雖然是自願的，但偶爾還是很懷念當初司機員無憂無慮的生活啊！但也跟之前學長說的一樣，當了司機員，你就會慢慢缺失想要進一步的念頭，我認為主要是接收到的訊息非常的固定，沒有新的刺激，你就會慢慢地停滯在原地，這是司機員需要自我克服的地方，而在資訊組這裡，你不會有這樣的感覺，每天都有不斷地新的資訊進來，會不斷地推進你往前，因為你不往前，你就會死得很難看啊！雖然周休二日，正常上下班真的不錯啊！但每天真的會忙成像狗一樣啊！累累的~所以回到家後，如何處理自己的時間也是非常重要的。

今年的內部招考又要開始了，這次企劃處和運務處有超多名額的，不知道朋友們會不會考上呢？對了，當初106期南段有7位司機員，走了一個，調單位一個，6月左右還要走一個，目前預計剩4位，快要低於50%了。

桃捷資訊組的二三事

Date: 20180410
Version: 1

這篇主要會是紀錄對於資訊組的一些想法與心得。

目前對於資訊組總結出三個困難點，腦袋難、人際難和規則難。

人際難，並不是組內不合諧，而是要處理各部門單位之間的聯繫很難。

規則難，這大概算是公部門的缺點吧，有各式各樣的流程，而且不會有人教你怎麼做，沒有SOP可以照著做，能做的只能是跟前輩詢問、打電話詢問承辦單位。

腦袋難，是上述這些事情都需要不斷地運轉你的腦袋，不然事情沒辦法做下去，沒有一刻可以放鬆一下。

寫到這裡，總是很懷念當初當司機員的生活，雖然沒辦法按時放假，需要輪班，但工作內容單純，沒有太多惱人的事情(多少還是會有)。

桃捷時刻表(簡易版)

Date: 20180318
Version: 1

因為負責公司官網的時刻表功能，而接觸到了時刻表，剛好司機員APP也剛好告一段落，就想說是不是可以利用一下手邊的資源來做個桃捷時刻表APP呢？

這就分成兩部份了，後台資料處理，需要將OCC提供的時刻表轉成我之後APP方便處理的格式，這部分是用Perl完成的，並不難，難的地方是在邏輯思考的部分，這部分就想了快一天左右，想出來後之後都很簡單做。

資料處理好後，接下來是就是APP的設計了，既然要做時刻表APP，當然要參考一下業界的形式，而個人最常接觸的就是台鐵的時刻表如下：

http://twtraffic.tra.gov.tw/twrail/TW_Quicksearch.aspx

因此，我的APP設計版面都是參考台鐵而來的，畢竟台鐵的時刻表查詢理論上也是國人最常用的，因此，若介面相似的話，理論上旅客都會比較容易使用。

接下來就是選擇日期的部分，發現AI2的日期選擇不太好用，所以上網找了資料後，將資料改成中文後，以及國人常使用的日期顯示格式後，並參考家人的意見進行修改，好不容易日期選擇的部分終於完成了。

選項設定好後，接下來就是時刻表資料匯入，這部分也是搞了好幾天，推倒了好幾次，終於把資料匯入了，並且使用Scroll和html格式，讓時刻表可以滾動，並上網查資料如何讓新的資料輸出時可以回到最上頭，也參考別人的方法後，終於讓APP符合自身的預期。

看起來非常像有這麼一回事一樣，不過如果這個要推出的話，就要放到google play上了，不過這就是公司的問題了，因為google play是要收錢的，我個人是不會這樣做的，所以只能用公司的名義去做，另外就是，目前公司的APP招標開始了，我的想法是雖然開始招標，等到決標也是4月的事了，再等到功能要上架後，也差不多要4-6個月，這一段空窗期，是否可以提供一個簡易版的時刻表APP呢？當初的想法是這樣的，剩下就要看長官是否覺得可行？

不過這個版面大概就是這樣了，主要是提供旅客簡易的查詢時刻表APP，所以應該不會放太多精力在上面，主要就是簡易，這個只要2.7MB就可以了，非常快速，而且跟火車查詢很像啊。


























後來在測試的時候，發現datepicker在第一次使用會有bug出現，後來發現是因為第一次loading的時候，會比較久，所以造成timer讀取產生錯誤，解決方法就是在開起應用程式時，就進行載入，這樣後面使用datepicker時就不會造成讀取錯誤。

桃捷司機員APP

Date: 20180127
Version: 1

繼之前寫過一次APP後，最近又開始新的專題，目標是多人使用，之前有做過一次，可惜失敗了，直到現在公司長官覺得可以推推看後，就打算再試一次看看，如果我做不出來，那推也沒必要了，這一次就快了許多，畢竟有個人版可以參考修改，我只花了兩天就做出來了，後面三天主要還是在做優化的部分，整體來說，比上次進步許多，尤其是Perl的hash觀念幫忙我許多，不過因為資料庫處理的關係，顯示速度稍微比個人版的慢了一點，可以看下方關於顯示速度的優化，基本上功能都用好了，接下來就看看長官們到底買不買帳，畢竟APP的使用目的是有限的，例如：「看一個月內的班表、想看其他人的換班」，這些都只能回去看LINE上的圖片，再來是副段們修改是在電腦excel上，之後再轉成圖片放在LINE上，之後就看他們有甚麼要求吧，畢竟他們慣用的excel格式跟我使用的還是有所差距，另外總班表更換時，他們也要跟著更動，除非這些都是由我來負責的話就沒差了，單純就我這邊操作也是可以的，不過一旦我離職，這APP就會跟著GG了。

之後就會更新一些公司的狀況，看看這個APP之後的方向會是如何的呢？

小寫開頭為number or string
大寫開頭為array
中間有底線為hash
中間有@為database，為從google試算表中拉出的原始資料

today: 今天日期
year: 今天年份, from today
month: 今天月份, from today
day: 今天日期, from today
driver: 使用者工號

Type: 班型
Time:  當月日期
Start: 上班時間
End: 下班時間
Extra: 加班時間
Detail: 任務內容
AllDetail: 所有資訊

Type@Database: 所有班型資料，含班型、上班時間、下班時間、加班時間、任務內容。
Driver@Database: 司機員資料，含工號、當月班型。

Driver_Schedule: 司機員相對應之當月班型
Time_Type: 當月日期對應之班型
Weekday_Name: 星期幾的中文名稱
Month_DayNumber: 當月份之天數
Type_Start: 班型相對應之上班時間
Type_End: 班型相對應之下班時間
Type_Extra: 班型相對應之加班時間
Type_Detail: 班型相對應之任務內容
Type_AllDetail: 班型相對應之所有資訊

完成部分：(*未完成)
今日顯示
工號清單
日期清單
任務清單功能
資訊顯示
班型按鈕顯示
今日按鈕顯示
工號清單功能
日期清單功能
使用者系統(第1頁輸入-->第2頁呈現)*
使用者鎖定(第一次輸入使用者後，再開啟會鎖定使用者，故不需上方的使用者系統)
返回按鈕顯示
月曆模式

顯示速度優化測試：
個人版：舊版，0.567秒
多人版：初版，各資料顯示放於各資料庫讀取階段，故2階段需1.101秒
多人版-2：統一資料顯示時機後，0.868秒，加快20%顯示速度
多人版-3：司機員匯入數量增加(3->57)，0.901秒，約慢了3%

自動化系統：(未完成，失敗，Net::Google::Spreadsheets安裝失敗，QQ)
修改完資料後，運用perl後會進行上傳至google試算表

Perl轉檔
perl會使用perl2exe轉成exe檔後，提供使用

特地去做了一個返回鍵的圖示，是用PowerPoint做的，效果還不錯，還蠻符合APP的色調。
以下為APP目前形式：

























後來，與中油的朋友討論時，發現中油也有輪班表APP，但他們只有4種班型，不會有個資的問題，所以他們的APP可以在Google Play上找到的，另外我也找到中鋼的APP，兩者的共通點都是只有4個班型，而且都是用月曆的模式來呈現，因此我也在思考是否可以做出動態的月曆出來，畢竟之前我是使用圖片的方式呈現。

經過一翻思考與設計後，月曆模式終於完成了，可以呈現出該月的班型狀況，使用三種顏色，藍色是當日，紅色是放假，灰色是上班，另本來打算是要在班型的地方改用按鈕方式呈現，但按鈕的效果不如預期，所以最後使用的是在月曆下方使用下拉是選單，來讀取班型內容，當然也有選擇使用者的功能。

目前，大致上會有三種版本，1)日曆模式、2)月曆模式、3)日曆+月曆模式，中油和中鋼是2，之前個人版算是1+2的圖片，理論上應該會是使用3的版本提供大家使用，當然最後還是要看使用者的意見決定之。

後來也仿照其他APP的功能，多做了一個關於的功能，放一些資訊，可供長官們發揮的區塊，另外還學習如何使用Email的功能，App Inventor 2的功能真是越來越厲害了，不過還是有許多地方還可以再改進。

經過一段時間後，Mail的功能已經做好了，並且也與車務中心開了兩次會議，中心主任甚至認為這個APP推出後，其他場域的人都會想用，不過最重要的是希望可以與公司的ERP系統介接，這樣資訊都會是最新最完整的，關於這部分，我剛好在看一些APP的作品有用到json的格式來達到類似的目標，所以如果可以將ERP的資料用json的格式丟出的話，理論上我這邊的APP應該是可以做到的，再來就是json資料的資安規範，要如何規劃，畢竟要接到我的APP一定是要透過外網來使用，所以外網的資訊安全就格外重要，目前公司這邊還在處理ERP資料拋出的部分，所以這部分就要等ERP部分處理好後，才會接下去，到時候可能就會再開一個新的文章了。

Unity小試身手-警察抓小偷

Date: 20180112
Version: 1

主要內容為在一個棋盤格式的地圖中，警察要在棋格上移動，找出小偷躲藏的地方。

規格：
Unity: Unity 2017.3.0f3 (64-bit)
Asset: Fungus
Android SDK：Android 6.0 API 23, Android Tool 25.0.0
JDK：jdk-8u77-windows-x64 (jdk1.8.0_77)

學習平台：
1. fungus詢問平台
https://muut.com/fungus#!/

2. 陳間時光 youtube
https://www.youtube.com/channel/UCXWxqnjzo4q6NhQiLhQFk7g


學習記錄：
collider -> clickable -> flowchart(can use object click action)
rigibody->collider->other.trigger(script needed)

Scripting > execute lua
-----------------------------------------------
local thief = getvar(flowchart, "Thief")
if (thief.value == 1)
then
thief.value = 2
--print(thief.value)
--return(thief.value)
end
----------------------------------------------
說明：
--註解
getvar 取得在flowchart中的fungus變數名稱"Thief"
local 只給fungus使用
thief.value = 2 將thief物件中的數值value改為2，此時fungus中的Thief會變為2
print(thief.value) 會在debug.log列印出來，除錯用
return(thief.value) 將thief.value回傳給Return Variable
Return Variable 要回傳的fungus變數，可為<None>
有return(...)，Return(<None>)，沒有回傳變數，故回傳值回傳後就不見了，程式正常
有return(...)，Return(...)，將回傳值回傳給回傳變數，程式正常
沒有return(...)，Return(<None>)，沒有回傳值，也沒有回傳變數，程式正常
沒有return(...)，Return(...)，沒有回傳值，有回傳變數，回傳失敗，程式error
lua if 結構式為： if () then {} elseif () then {} else {} end
lua 且(and )、或(or)，不是&&或是||



遊戲步驟：決策 > 移動

決策說明：(三者擇一)
1. 調查：可得知與之相連的棋格是否有小偷，return 有無小偷。
2. 部署：在原地點佈下警力，小偷不會進入此區域，但有持續時間/次數之限制。
2. 技能：可使用角色技能。

移動說明：選擇與之相連的棋格進行移動，return 有無小偷。
1. 有小偷：逮捕，遊戲結束，按照步數進行獎懲。
2. 無小偷：進行循環。

初始：
設定警察、小偷位置
1. 設定警察位置，九宮格共9個位置(set police.random = 1-9)
2. 設定小偷位置，不能與警察同格(set thief.random = 1-9,  while (thief == police){set thief.random = 1-9})

流程：
警察(決策>移動) > 判斷(抓住與否) > 小偷(移動)

決策：
調查：
1. 警察四周可移動之位置，確認是否有小偷，若有則回傳對話框saydialog，if (police == thief or police == thief ){}，使用lua撰寫。

部署：
1. 鎖定位置，讓小偷無法進入，但不影響警察進出。

警察移動：
1. 判斷自身位置(九種位置)(if police == 1-9)(9種){依照自身位置給出方向(角2、邊3、心4，上下左右(menudialog)}(24種)
    1-1. 判斷周遭狀況(部署)
2. 連至相對應的block(move to 1-9)(step++)(set police = 1-9)

判斷：
1. 若警察和小偷的位置一樣，則跳出對話後，給出兩種選擇"重新開始"、"結束遊戲"。

小偷移動：
1. 判斷警察和小偷位置後，使用if功能，確認出小偷可以移動之方向，若距離一樣，則使用隨機給出方向。
2. 使用lua。

目前會暫停這項計畫，發覺這遊戲好像沒這麼好玩，需要重新思考一下，可能會繼續卡牌遊戲的設計吧！

桌遊設定-2

Date: 20180101
Version: 1

主要還是延續桌遊設定-1的主題內容，但時間已隔許久，所以決定重開一章來繼續撰寫。

出生開始就邁入死亡 = 結構化-->失序化 = 不斷熵增的過程，而唯一的出入就是進化 = 就在讓自身再次結構化 = 達到熵減的結果。

所以遊戲剛開始有一個固定熵值，隨著遊戲時間進行，熵值會不斷增加，最後到達閾值，遊戲結束，因此，遊戲目的就是讓對方熵增加快(熵值增加，隨遊戲時間進行、讓對方受傷)，讓自身熵減(熵值降低，結構化=創造招喚物)。

利用招怪的方式，降低熵值，換句話說，也就是用熵值來進行招喚，故招喚物死亡後，也就是失序化，熵增。

熵值等於能量，能量可轉換為攻擊力、防禦力、效果、生命值，這四種是卡牌遊戲共有的，但四種太多了，困難度提高，因此需要降低複雜度，也就是說，需要把好幾種變為一種，以降低複雜度。

防禦力用來抵銷攻擊力，可以併入效果或生命值，剩攻擊力、效果、生命值，效果無法併入其他，剩攻擊力和生命值，兩者是否可以合併？生命值也就是體質，體質越好所蘊含的生命力更高，那是否體質越好的人，其攻擊能力越強呢？體質越好的人，其支撐這個身體的能量需要越多，來包括維持血液循環、神經反應、肌肉強度、肺活量...等，根據E=mc^2，能量越高，質量(體質)越高，再經由F=ma，也就是力(攻擊力)越高，因此，得出攻擊力和生命值是可以相容的，同理，當受傷時，生命值下降，體質降低，攻擊力也會跟著下滑，故兩者為正比。

最後結果為，能量 = 效果+ (攻擊力 = 生命值)，之後也會按照此規則進行設計。

遊戲背景設定：
在各種的計算之下，唯一得到的答案都是宇宙寂滅，所有的一切都將在宇宙大磨盤前化為虛無，於是乎在這樣的情境下，各種族不斷的嘗試各種超脫之路，期望自身可以擺脫那永恆的夢靨。
在各種超脫之路上，各種族專研各種降低熵值的方法，來達到永恆超脫的境界，而玩家扮演的就是各個種族，每個種族都有其專研的超脫之路，正所謂死道友，不死貧道，不需要跑第一，只要跑得比別人快就行了，各玩家就是在比拚誰能活到最後，誰擁有最多的時間來完善和專研超脫之路。

遊戲模式採類似「魔幻卡牌」的遊戲機制，完全不考慮牌運，也就是說一開始就可以使用所有的卡片，也因此卡片數量因展示空間有限，目前考慮為極數9來做一個規範，所以一個種族有9張牌可以使用。

再來是戰鬥部分，根據牛頓第三運動定律「作用力與反作用力」，攻擊別人時，力也會同時作用到自己身上，所以決不會有這回合我打你一拳，然後計算傷害，下回合你再打我一拳，然後再計算傷害，傷害是同時的。

而傷害結算就是，(攻擊力=生命值)互減，即A.attack-B.attack和B.attack-A.attack，戰鬥是同時發生的，不會有我先打在換你打的狀況發生，雙方攻擊力互減後，若攻擊力<=0，則滅亡，熵值則回復。再來是abs(A.attack-B.attack)的值是否要加到被消滅方的熵值上呢？這就要考慮到熵值的定義了，到底是個體熵值，還是種族熵值？若是個體熵值，則玩家本身就是個體，個體不會在招喚其他個體；若是種族熵值，則種族會招喚出個體，期望個體當中會有一個可以達成超脫，因而帶動整個種族達成超脫。

從上述得知，故熵值為種族熵值，因此，個體進行戰鬥損傷後產生abs(A.attack-B.attack)值，並不會影響到種族的發展。種族熵值預設為100，起始為50。

每一回後結束後，熵值會自動上升X值(5 or 10)，如同生命隨著時間慢慢步向死亡一般。

再來就是攻擊對象，有兩種可以選擇，1)可以自由選擇攻擊對象，例如遊戲王，2)只能攻擊對格怪獸，例如魔幻卡牌。(尚未決定)

再來是場上怪獸數量為3。

下怪的方式，因平常的遊戲是你一回合我一回合，是輪流放怪出來，所以後放的會看到先放的怪獸資訊，因而選擇相對應的怪獸，那是否需要當雙方都按下確認後，雙方才能看到對方選擇的怪獸。(尚未決定)(資訊透明的程度)

攻擊階段，是否可以選擇不攻擊？因攻擊後，勝利方生命值減少，下回合一定會被打死，如此循環，結果就會是第一個戰敗的會輸，但雙方都選擇不攻擊，這遊戲就不好玩了，沒有積極度。

再來是如果雙方同時進行攻擊，若其中一方有兩隻怪，一方只有一隻的情況下，要同時進行攻擊，A方，選擇A.1打B.1，因B.1血較少，而B方，選擇B.2打A.1，這樣B.2會活下來，對方會空場，且B.1可以直接攻擊玩家(先不論可不可以攻擊玩家)，這樣的情況下，雙方的選擇步一樣時該如何處理？若換成一方動完換另一方動，就不會有上述的狀況發生。

在上述的討論中，發現就牛頓第三運動定律而言，真正重要的是攻擊別人即是攻擊自己，因此，重點要放在攻擊對手後自己也同時會受到傷害，與互相輪流放置攻擊或同時放置攻擊並無相關，是屬於另一個議題，再來是受到傷害的來源是 1)對象的攻擊力，還是 2)自身的攻擊力。

1)對象的攻擊力
考慮到作用力與反作用力，故當自身攻擊時，就會受到對方攻擊力的攻擊力，因此兩者相減小於等於零時死亡，這也符合攻擊力=生命值的設定，再來就是當攻擊對方後，傷害溢出值abs(A.attack-B.attack)，因前項考慮後為個體損傷不影響種族，故傷害溢出值無實際作用，除非種族特色/效果所致，接著是攻擊結果，A為己方，B為對方時，共會有XX種狀況如下：
若A.attack > B.attack，A.attack=A.attack-B.attack>0，A存活，B.attack-A.attack<0，B死亡。
若A.attack = B.attack，A.attack-B.attack=0，A死亡，B.attack-A.attack=0，B死亡。
若A.attack < B.attack，A.attack-B.attack<0，A死亡，B.attack=B.attack-A.attack>0，B存活。

2)自身的攻擊力
考慮到作用力與反作用力，故當自身攻擊時，就會受到等同自身攻擊力的攻擊力，因此兩者相減為零，自身會死亡，這也符合攻擊力=生命值的設定，再來就是當攻擊對方後，傷害溢出值abs(A.attack-B.attack)，因前項考慮後為個體損傷不影響種族，故傷害溢出值無實際作用，除非種族特色/效果所致，接著是攻擊結果，A為己方，B為對方時，共會有兩種狀況如下：
若A.attack >= B.attack，A死亡，B死亡。
若A.attack < B.attack，A死亡，B存活且B.attack  = B.attack-A.attack。

會產生自身若攻擊比對方低，就不會攻擊對方的現象，所以是否強制雙方進行攻擊，但這樣子就會產生強弱強弱的循環，所以這時種族特色/效果的點就會出現，如何突破輪迴，就是要依靠種族特色/效果。


種族特色：

關於大數據的二三事

Date: 20171210
Version: 1

之後可能會被公司叫去處理大數據，因此，開始閱讀相關大數據的書籍，先求了解大數據的觀念，以及可能呈現的結果，再去學習相關的程式語言、統計分析和演算法等，目前程式語言是打算使用R來進行。

以下就會先記錄一些有關大數據的知識：

從大數據到智慧生產與服務創新
李傑、倪軍、王安正

系統式的數據收集和分析
利用資料解決可見問題，預測不可見問題，挖掘新的知識
特徵：從資料萃取出，與判斷事物的狀態或屬性有較強關聯的、可被量化之指標
主成分分析(PCA)
資料的廣度和深度
利用資料發現使用者需求缺口
從使用者資料擷取隱性知識，利用知識為客戶客製化
非對稱支援向量機演算法
同類對比
PCA-T^2
支持向量機(SVM)
資料特徵、映射模型、迴歸分析
K-L變換

大數據@工作力
Thomas H. Davenport

大量、缺乏結構、動態串流、多種格式

大數據商業分析─整合大數據與業務流程的高級商業分析指南
Nathaniel Lin

東方快車謀殺案

Date: 20171210
Version: 1

於20171209看完了電影版的《東方快車謀殺案》，隔天早上也翻了一下小說版，看看到底小說和電影有甚麼不一樣呢？

先說說電影的感想好了，我覺得還不錯看，雖然網上評價沒有很高，不管是有沒有看過小說，內容都還算不錯，不管是演技還是拍攝畫面，都有讓人覺得錢總算沒白花了，但到不至於說超值啦！只能說是等值罷了。\

沉澱幾天後再想想，覺得前面步調偏慢，但這個偏慢不是不好，意思是指他跟小說的步調差不多，但現在是電影，理論上要在更快一些，來到中段，節奏明顯變快了，但變快的時機慢了半拍，最後，開始加速了，最後一段飛快，太容易跟不上了，所以我覺得看到後面結束時，你的感想可能是"啥？這就結束了？"，而不是"喔~~~原來如此啊~~~"這種感覺，所以整體感覺上覺得比柯南差了一點，畢竟柯南還有動作片可以看。

小說與電影的不一樣，後來我又看了1974年拍的版本，因此，我打算就三個版本來討論一下，其中的差異，不會全列出來，就看我心情列，畢竟不同點實在太多了。

1. 關於白羅的人設，個人比較喜歡2017電影版的人物形象，1974的人設有點滑稽，2017比較符合我看小說的形象，但還是要先說我只看過白羅系列的這一集，可能等到尼羅河上市時，我會在去買下一集。

2. 再來是雷契特的人設，我比較喜歡1974的版本，而2017版的，我覺得太年輕了，應該由老綠魔來演會覺得不錯。

3. 布克先生，白羅的朋友，我還蠻喜歡2017版本的，年輕人，跟白羅是忘年之交的感覺。

4. 醫生在2017不見了，跟軍人合在一起，個人感覺不太好，最好還是跟小說和1974一樣，分成兩個人會比較好，故事最後，由布克先生和醫生共同決定說辭，如果只剩一個人，就會感覺強度不夠。

5. 在2017中有一點動作戲，1974則沒有，但我覺得一齣完全是多餘的，有夠蠢的，又不是柯南。

6. 再來是白羅的內心戲，2017實在是太多了，而且把白羅塑造成一個強迫症，這兩點在小說裡完全沒有表現出來，白羅有的只是對於案子的興趣而已，而且我認為在白羅的生涯中，他一定有過關於黑白灰三者的模糊交雜的狀況，也就是說他的人生經歷非常豐富，所以案件對他而言並沒有影響，案件就是案件，其中的人生大道理，他早有體會，所以在小說和1974中，他只說明的兩種選擇，並交由醫生和布克來決定要用哪一個？他對於結果(無論是A還是B)一點也不在意。

7. 個人比較喜歡1974的，比較忠於原著，2017改太多了。

8. 劇情方面，1974大約比2017多15分鐘的劇情長度，2017節奏太奇怪了，前段太慢，中段加快但已經跟不上該有的節奏，後段無限制加速，給人的感覺是"？？？這就沒了？"，而不是
"喔~~原來如此"，2017屬於前者，1974偏向後者，但還是有些太快，畢竟小說的篇幅還是比較長的。

9. 詢問的過程，1974是跟小說一樣，有一個特定的區域作為訪談的空間，而不是像2017的跑去每一個人的房間，哪有人辦案是要自己親自去跑呢？當然是一個一個叫過來約談啊！

10. 再來說畫面，不可否認，2017的畫面就是讚，畫面真的是很棒，列車看起來也很高級。

11.

東方快車謀殺案
阿嘉莎‧克莉絲蒂

Date: 20170813
Version: 1

偵探小說

120誕辰紀念版

在這之前我沒聽說過阿嘉莎‧克莉絲蒂，是因為今年10月有一部電影《東方快車謀殺案》(後來確定是12月上映)，聽說是很有名的偵探小說改編的，於是就買了原著來看，看看到時候電影和小說會有怎樣的差異呢？

故事的結論給了兩種答案，一個真的一個假的，但最後大家都選擇了假的，只因為兇手是一名殘忍的罪犯而已，說是一樁謀殺案，倒不如說是復仇罷了，但法律就是法律，如果不按照法律來進行，說穿了他們也只不過同樣是一群殺人犯罷了，本質上跟罪犯沒有差距，故事的最後給出這樣的結局，究竟是屈服於人的感性還是人的理性呢？這或許就是蝙蝠俠自身貫徹的正義吧！

最後就是等到10月來看看電影吧！(12月) 到時候再補充電影小說有什麼不一樣。

Java8學習手冊
      Ivor Horton
              ─個人Java隨手記

Date: 20171105
Version: 1

學習Java的過程中，紀錄相關重點，方便之後回來找答案。

private 確保只有在類別裡的函式的程式碼可以直接存取或改變那些數值
public 指明main()可以從類別外部作存取
static 指明main()如果沒有任何物件被定義的話，函式仍然可以使用
void 此函式沒有回傳值
string[] args 程式執行時所存取的資料，是由命令列傳過去的
byte > short > int > long > float > double 自動型態轉換(等號右至左)，若反向則明確型態轉換
import static java.lang.Math.*; // import static class number
enum 列舉型態
列舉.equals() 列舉函式，會將列舉內的數值與括號內作比較
列舉.values() 列舉函式，括號內為列舉中所有的數值
java -enableassertions MyProg // java -ea MyProg 錯誤警示
import java.util.Arrays; // Arrays.fill(arrayName, elementOfArray);
import static java.util.Arrays.fill; // fill(arrayName, elementOfArray);
群集for = foreach $_ (array){} = for(variable : array){}
字串比較string1.equals(string2) // string1.equalsIgnoreCase(string2) 忽略大小寫
objectName . methodName (arg1, arg2, ...) // 擁有此函式的物件.函式名(引數)
字串限定string1 = string1.intern() // 相同字串相同記憶體位置(==, 只比較記憶體位置)
import java.lang.Character // import static java.lang.Character
使用Scite進行編成：先使用Compile(Ctrl+F7, 此java檔案)/Build(F7, 此目錄下的java)，此時會產生class檔，再使用Go(F5)，就會出現結果
int[] array = new int[10] // 宣告與定義陣列

動畫圖解：資料庫系統理論─使用MariaDB、PHP、AppInventor 2 實作
                                                                                                             李春雄

Date: 20171105
Version: 1

程式設計

介紹PHP與資料庫基礎觀念

這是第二本介紹PHP與資料庫的書籍，而這一本比起上一本，個人更推薦這本作為新手入門，首先它的尺寸比同類型的書籍大，因此在閱讀上更舒服，第二文中輔以大量的圖示來輔助說明，可以讓人更淺顯易懂，最後，這本書在基礎觀念上的琢磨將近2/3~3/4的篇幅，而這一點對於新手才說，更貼近他們的需求， 特別是在觀念上的釐清與解釋非常到位，所以不管是新手學習還是老手複習，這些基礎觀念都說明得很詳盡，個人覺得非常推薦。

由於已經學過PHP和MySQL，對於書中許多程式都有一定的熟悉，但在基礎觀念上還有所欠缺，透過這本書，至少讓我對於資料庫的使用有更清楚的了解，現在開始轉戰Java，隨著學習各種程式語言，越發覺得基礎和觀念才是最重要的，而這一部份也是最難學也是最好學的，
最難學是因為是基礎，你需要的就是花時間在上頭，一分耕耘一分收穫，而最好學是因為世界有太多人跟你一樣基礎沒學好，只好上網找答案，現在只要Google一下答案就出來了，所以說這是最好的時代了，想學任何東西只要上網Google一下就可以了，差別只是你想學什麼？

PHP+MySQL與Dreamweaver互動式網站程式設計
                                                                         林梓涵

Date: 20171027
Version: 1

程式設計

介紹PHP、MySQL和Dreamweaver

因為公司內部有二次招考，有招考資訊的人才，所以想要去應徵，於是就去圖書館借了相關的書籍，借了許多書，發覺大概有兩本書還算不錯，對於剛入門的來講，今天的是第一本，在介紹這三種的基礎上非常扎實，讓讀者很容易的上手，不會有太多太艱深的內容，很適合初學者，另外，還會介紹相關的知識給各位讀者，所以我覺得還算不錯的入門書。

閱讀完後，大概了解到PHP其實語法跟Perl還蠻相似的，至於MySQL以前學過只是在更有系統地複習一遍，至於Dreamweaver就是個網頁設計軟體，市面上有許多類似的產品，你只要熟悉其中一個就好了，不一定要用Dreamweaver，這些網頁設計軟體大同小異，不會相差太多，習慣就好了。

至於第二本會等我閱讀完再作介紹，另外如果公司內部招考有考上，我會再發另外一篇介紹，如果沒有，就是我沒上，QQ，遺憾啊~~~~

美式卡通翻譯 Bunnicula

Date: 20171027
Version: 1

很抱歉通知各位，因版權問題，目前所有翻譯影片皆已下架，文章不會刪除，但是影片已經無法再觀看了，所以目前進行翻譯的動作會暫時放慢了，可能只會在私底下進行相關作業，不會再進行網路的分享，很抱歉事情的發生，但還是很感謝那些觀看過的人，至少我有做過這樣的事情，也算是一種經驗，之後部落格將恢復成原本的模式進行，感謝各位的觀看，謝謝。

[美式卡通翻譯] Bunnicula - S01E06：Garlicked

Date: 20171020
Version: 1

當Chester為了消除Bunnicula的魔力，而餵Bunnicula吃大蒜後，Bunnicula的毛全掉光了，變成一個可愛的跳舞骷髏，但Chester意識到，Mina如果發現Bunnicula是一隻真的吸血鬼，她會被嚇壞的，於是Chester和Harold必須想辦法解決這樣的問題。



註解：
1. 原文fraidy cat，形容膽小的意思，剛好Chester是隻貓，一語雙關。
2. 原文no bones about it，真實的，誠懇的
3. 原文humerus，肱骨，發音近似humorous(幽默)，一語雙關。

===========================閒聊分隔線===========================

這一集內容還蠻簡單的，很快就完成了。

最近看了Netflix的新影集，Mindhunter，超好看的，可惜正好看的時候，第一季就結束了，第二季要等到明年才會有，不知道他的原著小說好不好看，之前看了一些評論，小說比較像自傳稍微沉悶了點。

當開始工作後，才能體會到收到紅色炸彈，痛並快樂著是怎麼一回事，很高興有人結婚了，但很難過的是這個月開銷又增加了，畢竟開始工作，就不能像以前還是學生時期一樣，紅包意思意思就好了，這幾個月都存不到錢啊！

===========================閒聊分隔線===========================

本網站之所有翻譯作品均為個人學習翻譯技巧、並順便推廣冷門之美式動漫為目的，全由個人獨力完成，不應被用作任何其他形式之商業行為或打包下載之用。所有原作品的版權均屬於動漫原作者，任何在本網站之外的分享及商業行為，本部落格擁有者恕不負任何責任。本網站所有影片來源均由其他公開網路版面所取得，請有餘力的各位支持正版高畫質影片。