標籤

2019年6月20日 星期四

小說背景設定-15

Date: 20190620
Version: 2

海賊王中各種惡魔果實

靶靶果實(瞄準果實)
超人系果實,不同於原著中的果實,在目標形成一個標靶,初級時往標靶移動的物體會有些微自動校正的能力,隨著能力不斷增強,甚至會出現空間能力,會順移到標靶處,或者是因果能力,可以倒果為因,因為擊中才會有丟出的動作...之類的。

犬犬果實
動物系幻獸種,犬犬果實,狼狽型態,,可以同時獲得兩倍的動物果實能力,見唐.段成式《酉陽雜俎.卷十六.毛篇》:一說狽是一種似狼的動物,牠的前二足短,後二足長;而狼則前二足長,後二足短,狼與狽常相互搭駕走路或偷襲牲畜,理論上其幻獸種能力為"兩倍",將作用於自身的增益效果提升兩倍,減益效果降低二分之一,且因融合了狼與狽,其肉體能力將會是普通動物系果實的兩倍。

(其他可能設定)
可能具有狼狽為奸或狼狽不堪兩種能力,狼狽為奸:可以分身成兩人,一人雙手強壯,一人雙腳強壯,類似影分身之術的概念,所以可以透過兩個人訓練,融合後獲得另一方的知識;狼狽不堪:可以操縱疲勞,類似肉球果實的能力可以把疲勞彈開,而這裡只能單純的操縱自己/別人的疲勞。

超人果實
超人系果實,就像電影或漫畫中超人的能力,除了把氪石換成海樓石之外,理論上超人該有的能力都有。

花花果實
超人系果實,從資料可以得知,主角通常使用柔技或擒拿技居多,較少為剛拳類的,因此基於原著能力的介紹進行相關擴充,主要針對其能力「能力是從不同的地方,宛如開花般長出手、腳或身體各部位。」有二點可以討論:1) 長出的速度,2) 長出身體各部位。
先從第一點開始,長出的速度,F=MA,質量固定下,速度越快,作用力越大,因此參考死神市丸銀的斬魄刀「神鎗」,快速的伸出刀刃,造成像子彈的效果,因此加強伸出的速度再加上指槍或鐵塊的能力,造成類似神鎗的效果,再加上可以從身體各部位產生神鎗,效果應該會更難躲避。
接著是第二點,身體各部位的定義到底是甚麼?從原著可以看到手、腳、眼睛,推測身體各部位的定義最小單位為器官,因此是否可以在體內多長出一個器官呢?另外,這種能力可以參考獵人的尤匹的能力,以及黑貓最終BOSS的第三隻手設定。
因此,配合以上這兩種能力開發,理論上應該可以遠勝原著中的能力,原著中較注重在群體傷害的開發,而以上這兩種能力在單體對戰上會有大幅度的成長。

在生物課介紹過,多細胞生物的組成層次為:細胞-->組織-->器官-->系統-->個體。
在這要的邏輯之下,可以長出身體各部位,其是否包含從細胞到個體都可以,全賴於果實開發程度而定,這就意味著火影忍者中的,三身術(變身術、分身術、替身術)是可行的呢?變身可歸類為改變組織/器官組成結構,分身術則是個體的程度,替身術則可參考大蛇丸流·替身術,如此一來不管是群戰、單體戰、應用性上都有不錯的成果。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
摘自維基百科:

羅賓是超人系「花花果實」能力者,能力是從不同的地方,宛如開花般長出手、腳或身體各部位。此用途在偷襲方面相當具有效果,但是面對自然系的能力者以及軟體動物無效。花開的肢體分身遭到攻擊時,本體也會受到傷害。攻擊招式數字名稱是西班牙語,「クラッチ」(懸吊)是英語,「フルール」(花開)則是法語「花fleur」的意思。當羅賓使用能力的時候,經常習慣將雙手交叉橫置在胸前,周圍會有名為「飄飄花」(フワッフラワー)的花瓣在飛舞,凸顯羅賓招式的華麗度」
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

人人果實
動物系幻獸種(不確定是否為幻獸種???) 人人果實 巨人型態
身體可以變身成為巨人,普通狀態也會因果實能力而比一般人巨大,隨著能力增強,巨大的程度也會隨之增加,甚至可以比奧茲還要巨大,再來是可以進行部分巨人化,類似火影中的倍化之術,以及可以類似超級賽亞人4的型態,變為巨人後,進行壓縮來達到更強的戰鬥力。巨人,戰鬥民族,對於體術、六式、生命歸還、武裝色霸氣有極高的領悟,見聞色則相對的低。

影子果實
超人系果實,原著中真的是差勁的一蹋糊塗,理論上它有更好更強的開發。

  1. 可以發展類似火影奈良家的影遁。
  2. 類似刺客,隱藏在別人的影子中。
  3. 法則:陰影、黑暗、虛實、物質、能量、心靈、靈魂、空間。
  4. 影子具有實體的能力,且具有自身思維。
  5. 可以操縱、切割別人的影子。
  6. 可將影子附身在自己身上,在需要的時候展現,類似二次攻擊、千手佛、須佐能乎...等。
  7. 陰影侵蝕‧道心種魔,利用隱藏在影子中,透過類似邪神的呢喃、道心種魔的概念、寄生、感染的概念,進而控制別人、或是產生死士或狂信徒的概念,而且還可以提高被影響者的能力,進而吸引加入組織或國度。
  8. 透過陰影侵蝕,控制影子,並利用影子將實體拉入影中,進而取代實體,而原本的實體被拉入影子後,即可透過陰影侵蝕的方式感染原實體,最後達到兩倍的控制,爾後該實體既包含實體也包含影子,其能力素質倍增。
  9. 利用影子的特性,來產生飛雷神、分身、替身、變身術之類的能力。



我的英雄學院中各種個性

個性:黑水
皮膚可以化作黑色的水的模樣,外貌類似覆蓋武裝色霸氣的樣子,具有柔與剛兩種特性,柔,剛。

面積平均為1.85平方公尺(m^2),重量平均為8.5公斤(kg, 8.5E+3 g),平均厚度為2.25毫米(mm, 2.25E-3 m ),平均體積為4.1625E-3立方公尺(m^3, 4.1625E+3 cm^3),平均密度為8.5E+3 g / 4.1625E+3 cm^3 => 2.042 g/cm^3,水的密度為1,密度比水重。細胞厚度平均為1E-5 m,故以此厚度可展開成4.1625E+2平方公尺(m^2),約為126坪。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
皮膚是人體最大的器官,其重量占體重的14%~16%,一個體重為60kg的成年人皮膚約8.5kg,一個3kg重的新生兒皮膚岳重0.5kg,一個成年人的皮膚面積約為1.5~2.2㎡,新生兒約為0.21㎡,面積的大小與身高、體重成正比。
皮膚的厚度因人、因性別、因年齡、因職業等而異,一般為0.5~4.0mm

原文網址:https://kknews.cc/zh-tw/health/mn9jgp.html

人体的体表面积可以用Stevenson公式进行计算,即:
体表面积(m2)=0.0061*身高(cm)+0.0128*体重(kg)-0.1529
                                        --取自《生理学》

表皮厚度約為0.07~0.2mm
真皮厚度約0.3 ~ 3mm

原文網址:http://mikevgh.pixnet.net/blog/post/25185686-%E7%9A%AE%E8%86%9A%E7%94%9F%E7%90%86%E6%A7%8B%E9%80%A0

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

個性:肌肉增強/控制
也就是漫畫中的嗜血肌肉男的個性,肌肉又可以分成骨骼肌、心肌、平滑肌,依照各種小說漫畫的設定可分為:
海賊,六式,部分設定是認為血液的流動,可以透過肌肉來產生動力。
史上最強弟子,紅肌、白肌、粉紅肌。
殺神永生,余乾的羅剎和天狐。
火影,須佐能乎,肌肉增生可以產生類似的效果。
進擊的巨人,肌肉增生,同上,側重點不同。
電鋸使用手冊,血體,使用鮮血製造暫時器官,那是否也可以用雞肉製作暫時器官。

甚至在生物學上更進一步,控制肌肉的收縮,產生更大的力量,透過以上這些開發,絕對不應該被主角當成墊腳石。

文字戰爭

Date: 20190620
Version: 5

主要是我在Google play上看到一個遊戲,叫做「BattleText」,其實就是英文版的文字接龍,連結放在下面,大家有興趣的可以下載來玩玩看,還不錯玩。

玩著玩著,就想到是不是也可以做一個中文版的呢?而且上Google play查了一下,好像也沒有類似的遊戲產出,所以就想是不是可以自己做一個呢?

使用的工具還是App Inventor 2,大部分設定還是參考「BattleText」這個遊戲,之後在依照中英文的差異進行調整,製作步驟如下:

  1. 首先要有中文的字詞資料,後來就找到教育部國語辭典公眾授權網,有公開的資料可以使用,所以我就載了檔案下來。
  2. 接下來要處理這些文字資料,這些檔案都是EXCEL,我使用PERL,將EXCEL轉成JSON格式的字串,格式內容為:{第一個字:{字詞長度:[符合長度的字詞組]}},另外,為了增加字詞量,我又把唐詩三百首加進去,來進行擴充,接下來我就直接把整個字串貼進AI2中。
  3. 接著開始設計APP的介面,第一頁是參數設定頁,控制字詞量及電腦難易度,沒錯,這第一版我還是設計成單機版,後續若成功才會繼續規劃連線版,提供雙人對戰;而這些參數會使用TinyDB儲存。
  4. 第二頁則是對戰畫面,主要是復刻「BattleText」的畫面出來,包含色系,比較不一樣的是「BattleText」有自刻鍵盤出來,當然注音也是可以刻出來的,但這只是初期版本,其實不太需要,而且注音還會有注音比對的問題,所以這一版就沒有刻出注音鍵盤出來,再來是原作中有時間限制,目前這版本也沒有。
  5. 再來是中英文差異的部分,首先遊戲裡面的分數,是按照字詞長度來計算的,所以就要比較中英文字詞的長度差異,首先,英文部分,是拿網路上隨便幾則TOEIC必考幾千字的那種字串來計算,而中文則是拿教育部的資料來計算,目前計算結果是中文長度:英文長度=2.8:6.9;而分數又跟獲勝分數有關係,遊戲中獲勝是50分,依照比例計算,中文獲勝分數應該是20.3,四捨五入為20分。
  6. 結果還不錯,程式邏輯都不算難寫,使用MIT AI2 Companion,測試結果都可以正常運行,當然還有很多BUG出現,但那都是邏輯可以處理的問題,但最有問題的是,無法產出APK檔,但我的檔案也沒有很大,AIA檔沒有超過1MB,所以就開始試錯了。
    1. 刪除兩頁,正常。
    2. 刪除第一頁,有問題。
    3. 刪除第二頁,正常,合理懷疑應該是辭典出了問題。
    4. 刪除辭典部分,正常,那就是辭典有問題,但程式測試正常,可以正常運作。
    5. 所以我猜測是因為在一個TEXT的元件中,無法放太多或太長的字串在其中,因為基本上我把一個字典的字詞都放進去了。
  7. 所以綜上述所說的,大概有幾種解法,第一,改成網路連線抓取資料,使用Firebase,第二,就是分解我的JSON格式字串,降低單一元件的負載量,第三,改存成txt檔後上傳當附件,直接讀取附件;目前我嘗試過第三點,但是失敗了,不知道為什麼,總會有錯誤訊息產生,但明明內容就跟原本一樣,所以目前傾向第二點進行解決,後續持續更新進度。
  8. 有關此APP的相關截圖,請參考下方圖片1-5。
  9. 依照第7點進行改進,結果第二步驟還是太長了,無法轉成APK檔,所以只能朝第一點進行改進,目前測試如果將整個JSON格式字串上傳的話,下載下來的資料會有問題,所以還是會將資料分解後上傳,本來打算上傳後,下載存成內部資料,但不知道為啥,都無法順利下載,所以之後作法就是,將整體的資料流透過Firebase進行,而不進行存取在本機當中,後續持續更新進度。
  10. 為利於本案之進行,重新定義字詞存在的意義:
    1. 為了遊戲可以進行,而不是講一個無法接下去的字,而是在可以接下去的前提下,盡可能的提高字詞長度來達到高分,故進行以下調整,將字首和字尾沒有交集的去除掉,也就是說若字首無法是別的字尾,字尾無法是別的字首的話就去除。
    2. 循環字的去除,也就是指長度為2,且字首=字尾的去除,避免一直重複皆同一單詞。
  11. 後來在建置/使用Firebase上遇到一些問題,解決如下:
    1. perl重組後另存成utf-8格式之檔案。
    2. 修改副檔名為json。
    3. 用notepad++開啟後,可以看到編碼為utf-8<BOM>,請轉譯成utf-8即可。
    4. 上傳Firebase就完成了。
    5. APP Inventor 2上,單一頁面只允許存在一個Firebase的元件,超過1個以上的話,就會發生錯誤。
    6. 故在使用Firebase的元件時,需加入各狀態之標籤,確認要進行是哪一個Firebase的讀取。
  12. 終於完成了初版,可以真正打包成APK檔,並可安裝在手機裡了,可以正常遊玩,後來在玩的過程中,發現即使是長度(2~3)的難度,都是有難度的,因為電腦永遠先起手,永遠比玩家多2~3個字,如果是其他難度的話,就可能一開始玩家就輸不只2個字以上,這其實是蠻困難的,這也是因為中文與英文的差異,這部分之後再用統計的方式說明,所以在電腦起始時,不論難度為何,都是設定成長度2的字詞。
  13. 再來是遊玩時,當開始戰鬥時,第一個字詞的出現都需要等上一段時間,這很可能是與Firebase進行連線所消耗的時間吧?所以之後打算再加一個進度條的元件,讓玩家知道遊戲是正常運作中的。
  14. 再來是為了降低難度,將原有的3個難度,調整為6個難度,這也是依照中文字詞的特性進行重新分組,例如:長度4是因為成語,長度5是因為五言絕句/律詩,長度7則是因為七言絕句/律詩。
  15. 基本上已經完成了,接下來就是提供給其他人進行測試,點擊下載APK(連結),遊玩時,若有任何BUG或優化事項,都歡迎在文章下方留言,感謝協助。
  16. 目前一些改動如下:
    1. 已經加入進度條,避免以為APP當掉了。
    2. 電腦起始字,刪除一些沒有2個字的首字。
    3. 字典統一成一個,就如同英文就是一本字典,這也是中英文比較不一樣的地方,中文可以有很多類似:詩經、花間集、宋詞、元曲...等。
  17. 再來說說中英文統計上的差異:
    1. 英文平均長度為6.69,標準誤差是3.48,所以正負1.5SD的話,長度大概是3~10。
    2. 中文平均長度為2.5,標準誤差是1.38,所以正負1.5SD的話,長度大概是1~4。
    3. 所以從上面可以看出來,英文對於先手優勢沒有那麼大,因為標準誤差很大,很容易就在後面的單字上追上去,反過來,中文誤差較低,就顯得先手優勢很難追上。
    4. 英文因為長度,所以分數是50,依照比例原則,中文大約是18.65分,進位到十位數,變成20分會比較好看。
  18. 目前大概就是這樣了,如果沒有其他因素的話,更新大概就先這樣了,等以後有動力再來改。

圖片:
1. 第一頁,設定相關參數,包含辭庫量、電腦難易度,其實我也有想到還可以加入許多設定,包含時間限制、字串長度限制、獲勝分數限制...等。


2. 一樣要放的版權聲明,包含教育部的資料,及ICON的資料,我這次的ICON設計是無限之蛇,也就是銜尾蛇的概念,也就是接龍啦~~XD


3. 遊戲開始畫面,會先從電腦開始隨機出題。


4. 字詞輸入畫面。



















5. 獲勝畫面。 




















6. 中英文比較















參考文獻:
  1. BattleText
  2. 教育部國語辭典公眾授權網
  3. 漢語大詞典
  4. ICON

2019年5月14日 星期二

樂天知命─傅佩榮談《易經》
                                     傅佩榮

Date: 20190514
Version: 1

介紹易經的書籍。

當我決定要開始研究《易經》時,我就跑去買書,一共買了兩本,這是第一本,為什麼要買這一本呢?就要說到大學時期,也有一段時間在研究《易經》,那時候買了第一本關於《易經》的書,就是傅佩榮的《不可思議的易經占卜》,這就是我的入門書籍,可以說是傅佩榮是帶我進入《易經》的老師呢!

所以當我想要再開始研究時,第一時間想到的就是傅佩榮老師是否還有其他關於《易經》的著作,後來找了一下,就決定是這一本了,這本從各卦爻辭,再加上老師自己的見解,都寫在這一本書中,相當有參考價值,我認為《不可思議的易經占卜》當作入門參考書籍,而這本書可以當再更進階的版本,適合已經初步了解《易經》的同仁學習。

說到《不可思議的易經占卜》這本書,在我要離開學校生涯時,我就把它捐給學校了,主要是因為兩點,第一,希望可以幫助到其他人,第二,那時候我已經沒有疑惑了,所以捐出去,就象徵我放下了那一段過去,人生準備往前邁進了。

最後推薦給大家,《易經》值得擁有,如果不感興趣,還有很多你可以接觸的,總有一個是適合你的。

BTW,第二本等我看完再來分享吧!

2019年5月3日 星期五

生與死

Date: 20190503
Version: 1

最近家裡有親人逝世,那時候是在凌晨0點到1點左右,被電話緊急call去醫院,去看最後一面,對她來說,早點離世是比較好的選擇吧,畢竟活著對她來說,實在是太痛苦了。

總體來說,還是算享壽的,希望她在另外一邊可以過得很好。

但以上都不是這篇的重點,這一篇我想要描述的是,那天晚上去看最後一面時,所有的子女和孫子都來了,大家都哭了,比較激動的就哭成一團,但是,就我和我妹沒哭,我不知道為什麼,大家要哭成這樣,但也疑惑為什麼我們兩個不會哭呢?

我不知道答案,你要說我不難過嗎?也並不是,我會難過、會嘆息、會珍惜、會感嘆、會心塞、會遺憾、會可惜、會懊惱、會後悔、會不舍…等,但我就是不會哭泣。

我想我妹也是這樣吧。

最後以此篇紀念逝世的親人,願一路好走,祝福活著的親人,願身體健康。

2019年5月2日 星期四

易經占筮APP

Date: 20190502
Version: 1

最近又重新開始研究《易經》了,在大學和研究所時期,也有研究過易經,那時因為生活迷惘不知方向,所以開始研究包含易經、塔羅、京房、佛經...等,但後來隨者一個坎的邁過,我也放下了這些研究,生活重新步上軌道。

到了現在已經工作兩年多了,生活也十分穩定,想到是否可以發展第二專長,後來想想在研究的過程中,還是《易經》最讓人無法忘懷,大概是因為我花最多的時間在上頭吧!也因此決定要讓易經成為我的第二專長,透過它來幫助其他需要幫助的人,於是我又開始看起相關易經的書籍,並利用自己的專長,來寫一支易經占卜的APP,正所謂算卦容易,解卦難,使用APP可以輕鬆地算出一卦,但這一卦的背後故事就要看解卦人的功力了。

另外之所以會寫這支APP,是希望可以透過這支APP來增加我的樣本數,所謂的解卦,就是參考了卦爻辭以及解卦人的經歷來產生的,卦爻辭都在那裡,所以真正的重點就在解卦人的經歷上,而這就是需要增加樣本數的原因,樣本數愈多,我就愈了解卦應該如何解,才是最適合我的,解卦方式百百種,最重要的還是要找出自己一套的標準,這就需要樣本數及後續的追蹤,來不斷地修正自己的經歷。

以下就會說明我設計此APP的相關規劃:
  1. 會有一些用來占筮的功能,換句話說,會有不一樣算法的占筮,所以我設想要使用tablayout的方式來呈現,後來在app inventor 2的套件中,實在是找不到,最後我就自己刻出畫面來呈現tablayout的感覺。[圖1-5]
  2. 目前規劃會有5種tab,包含數字卦、時空卦、籌策、查詢、說明,共五種。[圖1-5]
  3. 在APP中使用資料庫來紀錄是否為第一次使用該tab,若是則會跳出說明視窗。[圖5]
  4. 數字卦,使用三位數數字來決定下卦、上卦和變爻,取餘數。[圖1]
  5. 時空卦,利用時間和經緯度來推算,取餘數。[圖2]
  6. 籌策,這就是繫辭中提到的算法,只是用程式寫出來,還蠻好玩的,中間的邏輯思考。[圖3]
  7. 查詢,簡單使用下拉式選單,讓使用者自行選擇要看哪一卦的資料。[圖4]
  8. 說明,第三點的說明,怕使用者忘記,還是可以在說明中查詢到,並加上聲明及電子郵件。[圖5]
  9. 目前APP大致上已經完工了,預計會上架到Google Play上,但會先再測試一段時間,來看看有甚麼需要優化的地方。
圖:
1. 數字卦




















2. 時空卦




















3. 籌策




















4. 查詢




















5. 說明,原本是其他























參考來源:
  1. 易雜談

2019年4月19日 星期五

易雜談

Date: 20190419
Version: 1

三易:簡易、變易、不易

人事時地物

六十四卦

占卜是為了問something物/someone人/somewhere地/sometime時/somehow事,簡稱為事物,故提出"事物"

找出獨特值為:人、時、地???

宇宙,也就是時空,時間和空間,換句話說,就是時間和空間是挷定在一起了,一個人的一個時間點,就代表著這個人在某個時間點只會在某個地方,故"時"等於"地"。

故獨特值為:人和時,要使用什麼做為計算標準?換句話說,也就是要找出人和時的代表的獨特值。

人的獨特值為:使用人名,也就是筆劃。
時的獨特值為:時間不斷變化,年月日時分秒。

人會產生一組固定的唯一值,但再加上時,就會產生一組非重複的獨特值。
時,因時制宜,依照需求可使用年/月/日/時/分/秒,例如:測今年運勢,就使用年即可。

就上述論述,應會使用算法1。

兩種算法:
1. 人+時給出1/64卦之一。
2. 人和時分別給出1/8卦之一,但會有上下爻之問題。

簡易:時人
變易:時
不易:人

算法:
人:使用筆劃,全部的筆劃?還是每個字的筆劃?林均穆 = 8 7 16
時:使用年月日時分秒,有需要轉成毫秒嗎?2018-12-31 23:11:11 <=> 1546225871,通常會是尾數在變,可倒轉。
兩者如何一起使用?相加?相乘?

數除8,得上/下卦
數除6,得變爻
數除64,得64卦

所謂天地人,天地,為時空,為時;人,為人,先有時,才有人,可得時人之序。

卦是由上往上長,故下卦為時,上卦為人,變爻為時與人交互作用之結果。
64卦由時人交互作用得來,變爻亦由時人交互作用產生。

時*人/64,得64卦
時*人/6,得變爻
時和人皆使用相連組成,
20181231231111*8716=175899611410363476
/64=20
/6=0
時的部分,最好使用reverse,可降低一致性。
例:
無reverse:20181231231111 和 20181231231112,相差1
有reverse:11113213218102 和 21113213218102,相差20000000000000
再經過除法後,結果不盡相同。

利用時空座標與人物,進行定位與推估,這就是占卜,故也就是使用當下的時空座標與人物進行定位鎖定與推估未來。

因此,確定使用REVERSE(YYYYMMDDHH24MISS) * CONCAT(stroke COUNT from each word of the NAME)
/64,得64卦。
/6,得變爻。

經過總總考慮後,僅保留時,因使用輸入人名方式,使用上不太便利,最後更改只使用時。
再來是一開始設想時空,時為時間,空為空間,時間就是time,空間用location,即可得經緯度。
時空,時空,先時在空,且時空相連,且空為經緯度,先經度後緯度,且經緯相連,
但經緯有小數點,故小數點取代後之數字串,
故總體而言,參數應該如下:
C#: YYYYMMDDHH24MISS + REPLACE(longitude,".","") + REPLACE(latitude,".","")
回傳如下:
/64,得64卦。
/6,得變爻。

2019年4月2日 星期二

小說背景設定-17

Date: 20190331
Version: 1

參考來源:「一個夢」。

主要是拿之前作夢的場景來進行設計規劃,盡量讓夢的內容貼近現實與邏輯之中。

  1. 兩段夢,都是第一人稱視野,也就是我,感覺上,這兩段夢的我,應該是同一個人,只是時間不連續,第一個夢應該是小時候,大概高中以前,第二個夢比較接近研究所或出社會時。
  2. 目前兩個夢沒有明顯之關聯,除了是同一個人之外,唯一有連接的大概是,我的超能力吧!先不論這是不是超能力,但印象中,在第一個夢中,我是個普通人,但第二個夢就不是了,合理推論,應該是第一個夢中,我去參加後,有了轉變。
  3. 所以推論是,第一個夢中的事情,我最後還是去了,也導致我獲得了什麼,但所謂有得必有失,也意味著我失去了什麼?我猜測應該是對於第一個夢中的記憶吧。
  4. 從第一個夢中得知,這個世界是擁有超凡的存在,但並非所有人都是超凡,另外,那個儀式應該是很古老的那一種。
  5. 再來說我的超凡,應該是可以控制和吸收水分吧!換句話說,我可以控制水,但無法產生水,因此,我要找一個可以產生水的工具,而那個女的,印象中會撐一把傘,因為到哪裡都會下雨,而且全身溼漉漉的,她就是我工具或者說武器吧!
  6. 那個男的話,大概是不死之身吧,類似亞人那種,但多了可以分解自身的能力。
  7. 所以時間線上,應該是夢1-->夢2,而在故事線發展上應該是夢1-->儀式-->走過門-->(事件)-->夢2,就目前主體應該是這樣,那麼事件到底發生了什麼事呢?
    1. 平舖直述的把事件說完。
    2. 因為某種事件造成主角遺忘此事件,人事物都還一樣,這一種會在未來使用閃憲法或倒敘法來補坑。
    3. 因為某種事件造成主角身分改變,人事物都改變了,應該是坑挖最大的,而這個事件影響範圍更大。
    4. 就上述三種,應該事件2或事件3是比較常用的。





2019年3月23日 星期六

一個夢

Date: 20190317
Version: 1

這裡要說的是一個我前幾天做到的夢,還蠻驚奇的,想說就把它紀錄下來。
  1. 一開始的夢,不知道在哪裡的東西上看到某些規則。
  2. 我覺得我符合,我就做了回應。
  3. 他們就要求我去,一個講日語的島嶼。
  4. 他們是雙胞胎,女生,有一個死了。
  5. 民國65年。
  6. 去的目的,不知道是要把她送回去,還是把她帶回來。
  7. 會有一道門,不知道是7道還是11道。
  8. 平常是有間隔,特定時間會拆掉後,會形成上述的們。
  9. 要帶著死去的她走過這一段。
  10. 之後夢醒了,跟我媽說不太想去。
  11. 後面就忘了,應該還有發生甚麼東西,但最後我就夢醒了。
整體來說,那個夢境給我的感覺,應該算是靈異類的吧,很像最近看的小說《電鋸使用手冊》的風格或是前著《殺神永生》也很類似,推薦大家去看看這部小說,還有作者前一部小說,真的超厲害的,作者應該是一書封神吧!

有機會的話,想把這個故事補完,對了,這個風格和《零~濡鴉之巫女》也是蠻類似的。

Date: 20190323
Version: 2

最近又作了一個類似的夢,直覺告訴我,這個夢應該是和上一次的夢是同一個世界觀,而且是接續在後面的,所以就來記錄一下吧。

  1. 一個男的和一個女的,在我家,我是第三個人。
  2. 女的好像一直哭,下雨天,撐傘。
  3. 男的施展了甚麼,變成一個墳墓。
  4. 下雨天,有一個快遞,開了鐵門,送了一個包裹進來。
  5. 我施展了能力,把包裹裡面的水和骨灰?分開。
  6. 骨灰就變成那個男的。
  7. 男的跑去回到過去?或回到陰間?去看女的會這樣的原因。
  8. 感覺上男的喜歡那個女的。
  9. 我和那個男的是朋友吧。
感覺風格和《電鋸使用手冊》還蠻類似的,尤其是快遞出來的時候,感覺就像是地獄使者(快遞員)的感覺一樣。


2019年3月17日 星期日

Vbot M625掃地機器人

Date: 20190218
Version: 1

在去年的時候就想買一台掃地機器人給父母用,終於在今年領到年終後,就決定要上網買了,但想說第一次買掃地機器人,不用買特別貴的,先試試看好不好用再說。

在屏東過年的時候,在電視台上看到國產介紹掃地機器人,也就是Vbot,看了一下影片覺得還不錯,就上網查了一下,評價都還可以,因此就決定買了。

我是在MOMO上買的,再加上拖地組,大約7500元左右,還算便宜,相關介紹就不說了,細節都可以在網路上查的到,以下講一些我媽對於掃地機器人的心得吧!


  1. 聲音有點大聲,不過還可以接受。
  2. 掃得很乾淨,比自己拖地還乾淨。
  3. 我媽不太用定時功能,她寧願自己在家要用的時候,再開啟掃地機器人,我的鄰居也是這樣使用的。
  4. 掃的速度算快,30分鐘可以掃兩三個房間,應該是沒問題的,整體電量大約1-2小時。
  5. 使用將近兩周,整體評價CP值很高,可以推薦給大家作為第一台掃地機器人來使用看看。
  6. 可能會需要的消耗品,過濾網和毛刷,這兩個是我媽覺得會需要再買的,價格也不貴,大約一組約80-100元左右,可以之後需要時再買。
  7. 拖地組終於打開來使用了,其實就是儲水箱和一塊拖地布,拖地能力尚可,大概一到兩個房間的量,水就回沒了,但其使用上並沒有那麼方便,所以建議是不需要額外加購此商品,使用原本的功能就很夠用了。
  8. 國產,而且才7000而已,可以買來試試看,之後下一台,可能會是小米二代,等之後年終的時候再說吧!

2019年2月24日 星期日

乳膠床墊

Date:
Version: 1

今年過年回屏東的時候,睡到一張床,非常舒服,可以很貼脊椎,因為原本的床算是偏硬的,所以那幾天在那張床的時候,竟然睡到打呼。

後來回到家後,再睡自己的床時,就非常的不習慣,所以趕快問一下表姐,那是什麼床,要去哪裡買?結果才知道這是乳膠床墊,而且是在屏東買的,店家是和晨寢具,我就請表姐幫忙看一下還有沒有貨,可以幫我買一個,後來,表姐去現場看了之後,發現廠商要清庫存,準備進新貨,所以打折出清準備換現。

最後就請廠商貨運到家裡,大約9000元左右,一開始會有一股味道,有人喜歡,也有人不喜歡,大約過了兩周味道就會很淡了,睡到現在,真的是非常好睡。

我買的是雙人大小的,厚度是5公分的,下面還有彈簧床,整體來說是真的不錯睡,推薦給大家,如果覺得自己的床睡起來有點硬,不是很貼脊椎的話,大家可以試試看,但如果真的不舒服的話,還是趕快去看醫生比較實在啦!





2019年1月27日 星期日

桃捷資訊組二三事

Date: 20190127
Version: 1


  1. 來到資訊組也滿1年了,中間真的是發生了許多事,但一轉眼間,就在資訊組待了一年,在桃捷也滿了兩年,時間真的是飛快啊,就來記錄看看這一年來到底發生了甚麼事吧。
  2. 前年12月剛到時,資訊組沒多少人,10人左右,每個人都超忙得,根本沒空理我這個新人,所以那時候的蜜月期超長的,爽到去年過年後,才正式分配工作出來。
  3. 我剛到就接手了一個離職人員的工作,再加上我自己的工作,真的是有夠多,而且大多數都是採購案,那時候真的是忙到翻掉,總結來說,要學會採購案,你要會先寫簽文,再來是採購流程,那時候對於採購案的了解大概就是這樣了。
  4. 後來,到了四、五月就是準備明年的預算,那時候才知道,原來公部門的預算都是這麼早就要進行了,真的是沒想到啊!
  5. 採購案完成後,就接下了APP採購案,這是一個500萬的採購案,評選標,不過前期部分的採購案進行,是請職級較高的人幫忙起頭,之後才交給我負責後續履約項目,但沒想到這又是另一個開始。
  6. APP採購案,第一次進行需求訪談,第一次這麼長時間接觸廠商,也因為這個案子,才慢慢了解到何謂採購案,到了後期,長官的加入,讓我更了解到機關應該如何面對廠商,以及甲方的優勢所在,也了解到廠商會如何應對。
  7. 在這個時期,說真的,跟當初我想像的不太一樣,我以為我會來寫寫程式之類的,結果沒想到會先經手這麼多的採購案,在經過這個時期後,才開始慢慢接觸到如何寫程式,對我來說,寫程式是一個陌生有挑戰性的工作,因為是非本科的,一開始寫程式還真的不知道怎麼開始,這時候Google和學長就真的非常有用。
  8. 也差不多這個時候,司機員要開始每月溫故訓了,對我來說,真的是非常爽啊,等於小放假,不用管辦公室內的事情,後來我就會開始將溫故訓排到連假前,然後選擇早B,4點半上班,等於可以多放半天,真的有夠爽的。
  9. 到了下半年,因為上半年排的教育訓練都在這時候,連續兩個月都有一周不用上班,超爽的啦!而12月時,我在自己排一個長假,等於這幾個月都只要15天左右,真的是有夠爽,預期明年也會這樣進行。
  10. 慢慢的就做到年底了,又是另一個開始,組內分硬體和軟體組,組織架構更佳明確,採購案也移到硬體組身上,就真的比較輕鬆了,有比較多的心力可以放在程式上頭。
  11. 而APP也到了另一個階段,而這次有長官的加入,真的輕鬆很多,也從長官身上學到許多有關採購案應該如何進行?應該對廠商採取何種態度?契約到底有甚麼用?
  12. 而這時候也了解到公司內有的單位,就真的是不知道在幹些甚麼?是誰我就不提了,提了真的是一堆鳥事啊!
  13. 很快就到過年了,這次提早很多天回去過年,盡量把事情都放在年後,我的年後應該會爆掉吧!XD
  14. 放假前,最後一個禮拜六去加班,第一次加好加滿,將近12個小時,是出外勤沿線檢查及收取物品,陪同的除了組內同仁,還有廠商,這時候才發現其實公部門的福利真的算是不錯了,因為廠商的薪水還是時薪,也沒有1.33、1.66、2.66之類的,這時候就會覺得我們怎麼這麼爽啊!
  15. 另外特別一提,放假的前一天一樣是司機員溫故訓,一樣是早B,4點半上班,而溫故訓的前一天,是在公司的最後一天,盡量把所有的事務處理完畢,所以可能會加班,在這樣的前提下,我申請了備勤室,可以直接住在公司裡ㄟ,這真的是第一次,到時候要來記錄一下,看看備勤室到底長什麼樣子。

2019年1月20日 星期日

無所不在的演化-如何以廣義的演化論建立真正科學的世界觀
                                                                                    馬特‧瑞德利

Date: 20190120
Version: 1

介紹各種演化

利用各種事物來闡明廣義演化論,亦或是利用廣義演化論來闡明各種事物

這本書,透過各種事物的歷史發展,來說明演化的觀點,又或者是用演化的觀點來介紹各種事物的發展,作者認為事物的發展,都有脈絡可循,也就是可以用演化的觀點來看待事物,不管是生物、物理、化學、宗教、政治、經濟...等,任何事物都不是一夕之間變化出來的,都是透過不斷地試誤、不斷地修改,才有了今天的容貌,而未來也將是現在不斷演化而生。

這部書中,最讓我驚訝的是,所謂的「天鉤」或是「大轉向」,也就是在發展以人為本時,突然間,轉向以神為本,認為一切皆為某智能創造者的產物,也因此,將科學的腳步停了下來,不再往前推進,而這一觀點,在這本書介紹的歷史中不斷重複發生,而我驚訝的點是,在很久以前,我看過的一部小說中,就寫到這種事,不過書中的解釋是,在外太空有一群外星人為了降低地球的科學發展,不斷地發送干擾給一些傑出科學家,讓他們「大轉向」,因而阻礙了地球的發展,我不知道那本小說的作者是否有做過相關研究,或是看過相關書籍而產生這種想法,但沒想到的是,我竟然在事隔多年後,再次看到這種狀況,真是讓人意外啊!

2018年12月11日 星期二

路線規劃APP

Date: 20181107
Version: 1

主要發想是來自於業務中,廠商使用Google Map來進行製作路線規劃,但其中有許多不太完善的地方,例如路線很奇怪,票價有問題...等,於是我就想說為什麼會這樣呢?難道很難嗎?於是上網查了Google Map API,詳細閱讀了文件後,覺得並沒有那麼困難,只是有很多參數需要加入,另外,在PTX中,也發現了正確的票價,使用以上工具可以解決我遇到的問題。

於是我就想做一個路線規劃的APP,但目前Android Studio還在學習當中,因此還是使用App Inventor 2來製作此APP。

  1. Google Map API,有12個月試用期,共300美元的額度可使用。
    • 會得到一組API KEY,呼叫API時使用。
    • 有JSON和XML兩種格式。
    • 有諸多參數可以設定,請查說明文件
  2. PTX,有分會員等級,但不成為會員還是可以用,只是額度更少
    • 會員有三種等級+未註冊,共4種等級,每一等級之權利義務不同。
    • 可提供預覽介面,可直接製作需要的API。
    • API中可輸入的功能很多,請查說明文件
    • 後來進行製作時發現,不成為會員的話,只能透過Swagger使用,無法在APP上使用,有權限管理,所以後來還是申請了會員。

製作過程:

  1. 需要先產生各路線對照表,包含place_id、代號、關鍵字、車站...等,並產生相對應的json object or array。
  2. 使用Google Map API及PTX API確認相關參數的使用狀況,決定後續要使用那些參數。
  3. 使用下拉式選單建立出路線和車站,提供路網圖給旅客查詢路線。
  4. Google Map API程式:
    1. 將車站轉出對應的place_id,並進行搜尋。
    2. 抓出連結資料。
    3. 將頭尾的步行刪除,因從車站出發。
    4. 抓出節點資料,利用關鍵字及路線校正,獲得正式名稱。
    5. 路線顯示。
  5. PTX程式:
    1. 找出同一家捷運公司的起迄站,並對應出各車站代碼。
    2. 利用代碼搜尋。
    3. 跟Google不太一樣,須建立header才行,請查說明文件
    4. 找出單程票票價。
    5. 將桃捷與北捷的票價加總,並顯示。
  6. 一開始使用圖片,但發現無法放大縮小,因此改為使用網頁瀏覽器,可以放大縮小,寫了個Html來展示台北捷運路網圖。
  7. 介面優化/程式優化,進行中。
    1. 介面優化:
      1. 步行圖示:🏃。
      2. 連接圖示:⬇。
      3. 端點站圖示:🌑。
      4. 轉乘節點圖示:🔘。
      5. 起訖站互換圖示:⇅。
      6. 路網圖圖示:🚇。
      7. 增加所有權聲明。
      8. 時間與票價介面優化。
      9. 時間與票價介面間距增加。
      10. 新增等待畫面。
      11. 新增第二頁面,顯示相關聲明、部落格及電子郵件。
      12. 修正A12、A13、A14a區間之文字訊息。
    2. 程式優化:
      1. 新增起訖站互換功能。
      2. 新增切換路網圖功能,及第一次無法切換設定。
      3. 新增端點站/轉乘站判斷功能。
      4. 新增焦點功能,每次查詢時,查詢結果可以置頂。
      5. 步行的顏色修正。
      6. 永春站的place_id修正。
      7. A18 高鐵桃園站的關鍵字修正。
      8. A13 機場第二航廈站的搜尋改善,使用fewer_transfers。
      9. 發現A12-A13之區間會有error,經查結果為google無論如何搜尋,都會跑出機場電車,該區間改成跳出文字訊息。
      10. BL 22 南港的關鍵字修正。
      11. 新增語音辨識功能,點選"起"或"迄"後,會出現google語音辨識起迄站,提高方便性。
  8. 製作APP的Icon [6]。
  9. 給公司的同事看過後,有人問到怎麼沒有台鐵和高鐵呢?若要達成台鐵及高鐵需要進行以下規劃及確認:
    1. 站點確認,台鐵太多站了,考量到此APP主要為桃捷及北捷,故預計規劃為北北桃生活區之區域,包含:
      1. 台鐵:五堵、汐止、汐科、南港、松山、台北、萬華、板橋、浮洲、樹林、南樹林、山佳、鶯歌、桃園、內壢、中壢、埔心、楊梅、富岡、新富,共19站。
      2. 高鐵:南港、台北、板橋、桃園,共4站。
      3. 已確認上述24站的place_id。
      4. 三鐵共構: 南港、台北、板橋,先使用同一組place_id。
    2. Google,確定參數"transit_mode=subway|train"適用於台鐵及高鐵。
    3. PTX,確認有台鐵及高鐵的票價資訊,已查車站代碼。
    4. 台鐵使用黑灰相間之格式,而高鐵則使用其網站主體配色(橘色)。
  10. 經過一個禮拜的努力,終於完成台鐵及高鐵的轉乘資料,由於不再是只有捷運,因此APP改名為「大眾轉乘」。
  11. 這幾天開始準備APP上架的相關事宜,開發APP到現在終於有第一個要上架的APP啊,超快,申請差不多一小時就過了,大家可以在Google Play上找到我的APP
  12. 成本估算如下,只要每日不超過1000人使用,應該就不需多付,當然我沒有開通付費功能,所以如果額度用完就沒了
    1. PTX:
      1. 免費。
      2. 呼叫次數:每日20,000次(一般會員),若每人一天兩次(上下班兩次),每次最多四種(北捷、機捷、台鐵、高鐵),20000/2/4,每日大約可供2500人使用。
      3. 參考資料:會員分級
    2. Google Map API:
      1. 每月有200美元的抵免額。
      2. 呼叫次數:每月40,000次(抵免額),若每人一天兩次(上下班兩次),每月22工作天,40000/22/2,每日大約可供909人使用。
      3. 參考資料:價目表
  13. 發佈後,有個朋友問是不是可以提供時刻表,回去查了一下PTX,桃捷、台鐵和高鐵可以提供時刻表,但北捷則因為班次較密集,使用時刻表意義不大,改成提供班次間距會比較好,只是這又是一個大工程了,而且是否要抓取整日的時刻表呢?還是提供查詢當下時間點之後的時刻表呢?有待商榷。
  14. 使用後第一個受惠的就是我,要去南京復興上課,平常都是做紅線轉綠線,使用了APP後發現,Google提供了一條,坐到松山火車站後,步行到松山捷運站,這樣的規劃非常不錯,去回程人少,而且都有位置坐,真的不錯,沒使用這個APP還不知道還可以這樣坐。
  15. 花了一兩個禮拜在這個APP上頭,是時候休息一下,看看書,等充完電後再來把時刻表補齊吧。
  16. 時刻表規劃:
    1. 北捷:提供班距說明。
    2. 桃捷:提供班距說明。
    3. 台鐵:提供起迄站時刻表。
    4. 高鐵:提供起迄站時刻表。

注意事項:

  1. header的使用須注意加密方式,時間格式為GMT,須扣除8小時,"x-date: "後面有空格,網址有時候用https會失敗,有時候會成功,目前使用http。
  2. 產生的json,可先用JSON Editor Online進行轉譯,比較容易了解。
  3. 如果不使用PTX,可使用Swagger將所有資料抓下來後,寫進資料庫也是可以,之前作法是將上傳到Firebase。
  4. 桃捷台北車站與北捷台北車站需步行,需多加留意程式撰寫。
  5. 上方的圖示是從Blogger中的"插入特殊字元"功能用出來的,可以搜尋關鍵字,找出你想要的特殊字元,就是上方的那些圖示,在網頁上呈現的結果,會與APP上呈現的結果不太一樣。
  6. 北捷的路網圖要跟北捷申請授權,也就是填一份授權申請書,回寄給北捷即可。
  7. 憑證keystore,自己包的APK使用的憑證,和從Google Play下載的APK憑證會不一樣,所以在Google Cloud Platform限制使用時,要特別注意其使用的SHA1會不一樣。
  8. 在Directions API中有一個參數為alternatives,若設定為true,則會像google map一樣顯示出多條替代路徑,而我沒有採用的原因有1)太多條,不知道哪一條才是我要的,還是用預設最符合我需求的那條即可,2)太多條,計算的量不一樣,API的價格也不一樣。
  9. 發現使用的憑證錯誤,會導致API設定後無法使用,將進行釐清到底要使用哪個憑證?
    1. 無:沒有限制,可使用,看來只能使用這個了,多加了API限制。
    2. 應用程式簽署憑證(google核發):經修改五分鐘後測試,無法使用。
    3. 上傳憑證(原app):經修改五分鐘後測試,無法使用。


改進事項:

  1. 抵達A13時,有時候會出現Error,因會出現到A12轉乘機場內的接駁車造成程式錯誤,轉乘錯誤: A13(fewer_transfers)、確認json資料(For input string: "ot")。
  2. A1-A5區間至A7的票價錯誤,因PTX未更正正確資料,已請同仁處理。
  3. 板南線任意站到南港展覽館站會出現錯誤。
  4. 起訖站互換功能錯誤。
  5. 目前使用上,若起訖站含有轉乘站(台北、桃園、板橋、南港、A1、A18),或地理位置鄰近(北門),會出現顯示不易理解之情況。
  6. ...
參考文獻:

  1. Developer Guide | Directions API | Google Developer
  2. Place ID Finder | Maps JavaScript API | Google Developer
  3. 入門指南‧PTX API Documentation
  4. MOTC Helper
  5. JSON Editor Online
  6. 台北捷運路網圖
  7. 3418 free SVG and PNG icons for your games and apps | Game-icons.net



2018年11月18日 星期日

ASUS AIO ZN242GDK 使用心得

Date: 20181118
Version: 1

我妹買了一台ASUS的AIO,家裡之前都是買桌機,沒買過這種的,所以上網找了一些資料,後來,我妹覺得很適合她,沒有主機,不占位子,就是一個螢幕,很方便。

所以上網看一下使用心得後,就決定買了,買回來後,幫她安裝一些必要軟體後,就讓她繼續摸索一下,並請她使用後一周,給我個使用心得。

ASUS AIO ZN242GDK規格:

  • 螢幕:23.8” FHD 1920X 1080 LED-backlit 
  • 觸碰功能:無 
  • 顏色:銀 
  • 處理器:Intel Core i7-8750H(2.2GHz, up to 4.1GHz) 
  • 記憶體:16G (8Gx2) DDR4 
  • 硬碟:1TB (5400RPM) 
  • 固態硬碟: 256G M.2 SSD 
  • 顯示介面:NVIDIA® GeForce® GTX1050獨顯 
  • 其他:802.11ac+Bluetooth 5.0 
  • 光碟機:無,請自行選購 
  • 作業系統:Windows 10 家用版(64bit) 
  • 其它:2合一讀卡機 
  • 配件:鍵鼠組 
  • 保固:3年保固, 到府收送 

超棒的規格,但我妹又不打電動,真的是非常可惜啊~~

反正她爽就好。

使用心得(PDF)

2018年11月4日 星期日

追蹤開膛手傑克─DNA科學鑑識解密百年懸案(2)
                                                           羅素‧愛德華茲

Date: 20181104
Version: 1

這篇主要是因為之前玩過一款"白教堂"的桌遊,內容就是在講開膛手傑克,發現大家似乎都不知道開膛手傑克是誰,就想起之前讀過的這本書籍,於是就拿了出來,並做成一個簡要的說明。

為什麼會推這本呢?主要還是因為其內容使用了各種科學鑑定的方法來證明開膛手傑克是誰?

提供相關說明如下,有興趣的可以看一下:


2018年11月1日 星期四

Android Studio學習筆記

Date: 20181013
Version: 1

主要是用來記錄學習Android Studio的過程紀錄。

1. build.gradle

##
apply plugin: 'com.android.application'

android {
    compileSdkVersion 28 <= 這邊要注意,故SDK須要API 28
    buildToolsVersion "28.0.3" <= 這邊要注意
    defaultConfig {
        applicationId "com.blogspot.iamamu.first"
        minSdkVersion 22 <= 這邊要注意,故SDK須要API 22
        targetSdkVersion 28 <= 這邊要注意
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation 'com.android.support:appcompat-v7:28.0.0' <= 這邊要注意
    implementation 'com.android.support.constraint:constraint-layout:1.1.3'
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 'com.android.support.test:runner:1.0.2'
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
}

##

2. ADM

使用API 22 x86 Google API 即可

3. 翻譯文字

使用locale zh TW即可,@strings/"字串"

4. 熱鍵

Ctrl + Alt + L:重新排版
Ctrl + F1:more 說明
Alt + Enter:檢查錯誤,並提供修正參考

5. 目前在寫按鈕按下後,呈顯會加一,寫完當下,Android Studio會先自檢,若有錯誤,則會跳出紅色折線,目前寫完是沒有出現這樣的狀況,但不知為何,每次運用模擬器時,都會當掉,下次我會用公司的電腦試試看,看到底哪裡出現了問題。

/*MainActivity.java
package com.wood.second;

import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;

public class MainActivity extends AppCompatActivity implements View.OnClickListener {

    //宣告
    private Button button = findViewById(R.id.button);
    private TextView textView = findViewById(R.id.textView);
    private int count = 0;


    @Override

    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        button.setOnClickListener(this);
    }

    @Override
    public void onClick(View v) {
        count++;
        textView.setText(count);
    }
}
*/

6. 在公司試了半天,終於找到原因了,也順利run起來了,要注意的點是

  1. 要先宣告,但不先不賦予值。
  2. 再來onclick內要有確認ID的動作。

/*
package com.wood.second;

import android.annotation.SuppressLint;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;

public class MainActivity extends AppCompatActivity implements View.OnClickListener {
    private Button btnplus, btnminus, btnreset, btnmulti, btndiv;
    private TextView txv;
    private int count = 0;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        btnplus = findViewById(R.id.button);
        btnminus = findViewById(R.id.button2);
        btnreset = findViewById(R.id.button3);
        btnmulti = findViewById(R.id.button4);
        btndiv = findViewById(R.id.button5);
        //Button btnplus = findViewById(R.id.button);
        //Button btnminus = findViewById(R.id.button2);
        txv = findViewById(R.id.textView);
        //count = 0;
        btnplus.setOnClickListener(this);
        btnminus.setOnClickListener(this);
        btnreset.setOnClickListener(this);
        btnmulti.setOnClickListener(this);
        btndiv.setOnClickListener(this);
    }

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            case R.id.button:
                count++;
                break;
            case R.id.button2:
                count--;
                break;
            case R.id.button3:
                count = 0;
                break;
            case R.id.button4:
                count *= count;
                break;
            case R.id.button5:
                count /= count;
                break;
            default:
                break;
        }
        txv.setText(Integer.toString(count));
    }
}
*/

7. 如何解決setText會出現建議事項,提供參考網站,【Android寻坑之路】解决TextView.setText提示Do not concatenate text displayed with setText. Use resource string with placeholders.问题,文章中大約出現了4種轉字串的作法如下:

  1. @SuppressLint("SetTextI18n"); txv.setText(Integer.toString(count));
  2. txv.setText(String.valueOf(count)); <=詢問寫java的人,比較常用
  3. StringBuilder a = new StringBuilder(); txv.setText(a.append(count)); <=詢問寫java的人,比較常用
  4. android:text="@string/number" ==> <string name="number">%1$d</string> ==> txv.setText(String.format(getResources().getString(R.string.number),count));

8. 解決了按鈕的問題後,接下來要試試看下拉式選單,參考"GiveMePasS'S Android惡補筆記-如何使用Spinner(下拉式選單)"這一篇文章。再來是整體設計,會有一個按鈕,按下後會隨機取樣(1-10),這個數字就是下拉式選單中會有多少選項。

也順便學了java的相關函式:

  • Math.random()
  • ArrayList<> = new ArrayList<>();
  • ArrayAdapter<> = new ArrayAdapter<>();
  • ArrayList.add()
  • ArrayList.clear()
  • ArrayList.get()

整體來說,還不錯,再接再勵往專業邁進。

9. 下拉式選單完成後,我接著挑戰日期和時間,也一樣上網爬了文,DatePickerTimePicker,這兩篇對我幫助很大,後來也自行修改到可以記錄上一筆選擇的項目,不會每次點進去都是同一時間,也學了許多java函式:
  • Calendar = Calendar.getInstance()
  • Calendar.set()
  • Calendar.get()
  • Calendar.YEAR
  • Calendar.MONTH
  • Calendar.DAY_OF_MONTH
  • Calendar.DAY_OF_WEEK
  • Calendar.HOUR_OF_DAY
  • Calendar.MINUTE
  • String.format("%d...", ...)
  • Key-Value Pairs:
    • Map<> = new HashMap<>()
    • HashMap.put()
    • HashMap.get()

/*

import android.app.DatePickerDialog;
import android.app.DatePickerDialog.OnDateSetListener;
import android.app.TimePickerDialog;
import android.content.Context;
import android.renderscript.Int3;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.AdapterView;
import android.widget.ArrayAdapter;
import android.widget.Button;
import android.widget.DatePicker;
import android.widget.EditText;
import android.widget.Spinner;
import android.widget.TextView;
import android.widget.TimePicker;
import android.widget.Toast;

import java.util.ArrayList;
import java.util.Calendar;
import java.util.HashMap;
import java.util.Map;

public class MainActivity extends AppCompatActivity implements OnClickListener, AdapterView.OnItemSelectedListener {
    private Button btnplus, btnminus, btnreset, btnmulti, btndiv, btnrand, btninput, btndate, btntime;
    private TextView txv, txv2, txv3;
    private Spinner spin;
    private int count = 0;
    ArrayList<String> randomList = new ArrayList<>();
    private EditText editxt;
    private Map<Integer, String> dayOfWeek = new HashMap<>();
    final Calendar time = Calendar.getInstance();
    private int myYear = time.get(Calendar.YEAR), myMonth = time.get(Calendar.MONTH), myDay = time.get(Calendar.DAY_OF_MONTH), myHour = time.get(Calendar.HOUR_OF_DAY), myMin = time.get(Calendar.MINUTE);

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        btnplus = findViewById(R.id.button);
        btnminus = findViewById(R.id.button2);
        btnreset = findViewById(R.id.button3);
        btnmulti = findViewById(R.id.button4);
        btndiv = findViewById(R.id.button5);
        btnrand = findViewById(R.id.button6);
        btninput = findViewById(R.id.button7);
        btndate = findViewById(R.id.button8);
        btntime = findViewById(R.id.button9);
        txv = findViewById(R.id.textView);
        txv2 = findViewById(R.id.textView2);
        txv3 = findViewById(R.id.textView3);
        txv.setText(String.valueOf(count));
        spin = findViewById(R.id.spinner);
        editxt = findViewById(R.id.editText);
        btnplus.setOnClickListener(this);
        btnminus.setOnClickListener(this);
        btnreset.setOnClickListener(this);
        btnmulti.setOnClickListener(this);
        btndiv.setOnClickListener(this);
        btnrand.setOnClickListener(this);
        spin.setOnItemSelectedListener(this);
        btninput.setOnClickListener(this);
        btndate.setOnClickListener(this);
        btntime.setOnClickListener(this);
        dayOfWeek.put(1, "日");
        dayOfWeek.put(2, "一");
        dayOfWeek.put(3, "二");
        dayOfWeek.put(4, "三");
        dayOfWeek.put(5, "四");
        dayOfWeek.put(6, "五");
        dayOfWeek.put(7, "六");
    }

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            case R.id.button:
                count++;
                break;
            case R.id.button2:
                count--;
                break;
            case R.id.button3:
                count = 0;
                break;
            case R.id.button4:
                count *= count;
                break;
            case R.id.button5:
                count /= count;
                break;
            case R.id.button7:
                count = (editxt.getText().length() == 0) ? 0 : Integer.valueOf(editxt.getText().toString());
                //count = Integer.valueOf(editxt.getText().toString());
                //txv.setText(editxt.getText().toString());
                break;
            case R.id.button6:
                int rand = (int) (Math.random() * 10 + 1);
                randomList.clear();
                for (int i = 1; i <= rand; i++) {
                    randomList.add(String.valueOf(i));
                }
                ArrayAdapter<String> randomAdapter = new ArrayAdapter<>(this, android.R.layout.simple_spinner_dropdown_item, randomList);
                spin.setAdapter(randomAdapter);
                break;
            case R.id.button8:
                //final Calendar time = Calendar.getInstance();
                //myYear = time.get(Calendar.YEAR);
                //myMonth = time.get(Calendar.MONTH);
                //myDay = time.get(Calendar.DAY_OF_MONTH);
                //myDate = time.get(Calendar.DAY_OF_WEEK);
                //txv2.setText(String.valueOf(myYear) + String.valueOf(myMonth + 1) + String.valueOf(myDay) + String.valueOf(myDate));
                new DatePickerDialog(this, new OnDateSetListener() {
                    @Override
                    public void onDateSet(DatePicker view, int year, int month, int dayOfMonth) {
                        time.set(year, month, dayOfMonth);
                        myYear = year;
                        myMonth = month;
                        myDay = dayOfMonth;
                        txv2.setText(String.format("%d-%d-%d (%s)", year, month + 1, dayOfMonth, dayOfWeek.get(time.get(Calendar.DAY_OF_WEEK))));
                        //txv2.setText(String.valueOf(year) + String.valueOf(month + 1) + String.valueOf(dayOfMonth) + " (" + dayOfWeek.get(time.get(Calendar.DAY_OF_WEEK)) + ")");
                    }
                }, myYear, myMonth, myDay).show();
                break;
            case R.id.button9:
                    //myHour = time.get(Calendar.HOUR_OF_DAY);
                    //myMin = time.get(Calendar.MINUTE);
                    new TimePickerDialog(this, new TimePickerDialog.OnTimeSetListener() {
                        @Override
                        public void onTimeSet(TimePicker view, int hourOfDay, int minute) {
                            time.set(myYear,myMonth,myDay,hourOfDay,minute);
                            myHour = hourOfDay;
                            myMin = minute;
                            txv3.setText(String.format("%d:%d", hourOfDay, minute));
                        }
                    }, myHour, myMin, true).show();
                break;
            default:
                break;
        }
        //txv.setText(Integer.toString(count));
        txv.setText(String.valueOf(count));
    }

    @Override
    public void onItemSelected(AdapterView<?> parent, View view, int position, long id) {
        count = Integer.valueOf(randomList.get(position));
        txv.setText(String.valueOf(count));
        //Toast.makeText(this, "The number is: " + randomList.get(position), Toast.LENGTH_SHORT).show();
    }

    @Override
    public void onNothingSelected(AdapterView<?> parent) {

    }
}

*/


2018年10月26日 星期五

溯源探幽-熵的世界
            馮瑞 馮少彤

Date: 20181026
Version: 1

介紹熵的一本科普書籍,是一本簡體的書籍。

整體來說,可以提供給非專業的同仁來閱讀,並不算太深奧,應該是說雖然有很多公式,但都會以許多字句來輔助說明,並不會太艱深難懂。

整本從熱力學第一定律講到第三定律,從淺入深,一步一步帶我們進入熵的世界。

熵與能,我覺得是一種一體兩面的存在,兩者彼此影響,但總體來說,在這本書的進展從能慢慢轉移到熵,也慢慢地都注重在熵的發展,也看到熵如何影響物理學、化學、材料學...等科學領域上,非常推薦給非專業領域的同仁來看,可以一見熵的面貌。

雖然如此,但文中也有大量的公式,所以對我來看得有點慢,再加上最近這段時間很忙,回到家就只是想打個電腦休息一下而已。

最近玩了一個桌遊是白教堂,也就是開膛手傑克的故事,而我也在之前有介紹過一本書,說明科技如何找到傑克的故事,也發現好像很多人不了解這件事,所以之後可能以做一個懶人包為目標吧~~

追蹤開膛手傑克─DNA科學鑑識解密百年懸案


2018年10月13日 星期六

Google Android 程式實戰演練 - 使用 Android Studio 與 Android SDK 打造雲端商務應用程式

Date: 20181013
Version: 1

課程:Google Android 程式實戰演練 - 使用 Android Studio 與 Android SDK 打造雲端商務應用程式
公司:恆逸教育訓練中心
時間:2018-10-08至2018-10-12 每週一二四五 09:00~17:00
地點:台北市復興北路99號12F
價格:19,200元

課程的相關資訊如上所示,會寫這一篇的原因,主要是因為公司出錢,讓我去上關於Android開發的課程,之後,可能要自行開發公司用的相關app。

雖然是公司出錢,但是我先墊的,之後要寫一份心得,才能進行動支,錢才會匯回來,所以這篇也是順便寫的,不過有些內容就不適合放了,這次上課時間是10月10日,放假那一週,原本我是想要那週請長假,結果發現早在幾個月前就安排了課程,只好乖乖去上課了。

也剛好前一周,我進行採購案的估查驗,超忙的,也因為下一周我不在公司,所有的事都須要在那一周做完,真的是有夠累的,幾乎每天都要加班。

~~~

這次上課的內容,對我來說算是比較進階的課程,我之前只會少許的Java,而且之前製做APP的工具也不是Android Studio,所以整堂課下來,對我來說是有那麼一點困難。

課程的講義則是將各個單元的簡報印刷成一本,不太算特別,內容也有許多與目前實際內容有所出入,應該是沒有進版的關係吧!

上課中,老師補充了許多目前APP的發展有關的相關資訊,這也是上課才可能會聽到的東西,畢竟在公司只要把事情做好就好了,想要了解最新的資訊,就只能利用下班後的時間,但問題是如果你不知道有哪些新東西,你又要從哪裡去找你不知道的東西呢?

第一天上課的時候,大家都還能跟上自己動手作,但到了第二天,大家基本上都只能操寫老師的程式碼,複製完之後,再來自己慢慢看了,老師的進展真的是飛快,這也沒辦法,因為要在4天的課程中,將APP的相關程式介紹一遍,大概也只能用這樣的方式吧。

11月還有一次,不過是三天,希望課程內容可以再簡單一點,不然真的會吸收不上。

我的電腦規格:
CPU: Intel Core i5-3210M
RAM: 8GB
無SSD

~~~

其實在今年六月的時候,我就用我的電腦試過了,結果超慘的,連啟動都沒有辦法,但經過上課之後,了解比較多的細節後,會自己將缺少的部份加回去了,至少現在程式是可以啟動的,模擬器也是可以啟動的,之前一樣也不行,果然有上課是有差的,雖然程式可以啟動,但我還是不會寫程式,我連按按紐都寫不出來,雖然程式沒跳錯誤,但每次模擬器就是會當掉,把我寫的那一段刪掉後,又恢復正常,我還是要繼續研究才行。

但最讓人頭痛的是,我的電腦實在是跑太慢了,每一個動作都要等上一會兒才行,你輸入太多,電腦還會當掉,哀~~

來講一些題外話,在恆逸上課的感覺,我覺得還不錯,設備用起來都很順,每一個學員都有自己一套課堂用的抽取式OS,上課時,只要簽到就可拿到你的抽取式OS,放入電腦開機就可以了,比我之前去其他上的電腦課程好太多了,簽到的時候發現,上課的人有一半都是相關公營機關:北捷、桃捷、台灣菸酒…等的,看起來大家都是長期使用恆逸來上一些資訊相關的課程。

說真的上一週實在是有夠累的,這一週可以拋開公司大小事,專心上課也算是另類的放假吧,下周又要回去公司了,有超多事情在等著我吧,QQ~~

基本上我覺得恆逸上課還不錯,介紹給想要上相關課程的人,不過價格真的有點貴啊!

後續學習心得
1. Android Studio學習筆記

2018年9月30日 星期日

韓劇《Good Doctor 善良醫生》 VS. 美劇《The Good Doctor 良醫墨非》

Date: 20180930
Version: 1

最近在電視台上看到,由韓劇改編的美劇,善良醫生,其實早在幾年前看完韓劇時,就知道會被改編的消息,只是不知道甚麼時候才看得到,直到不久前才從電視廣告中得知。

所以就趕快跑去看了,第一季共13集,也在今年出了第二季,目前正在follow中。

看完第一季就來聊聊兩者的差異吧!會以條列式進行,以下相關內容是依照幾年前看的韓劇與最近看的美劇進行比較,可能會因時間久遠產生誤差。

以下劇透,不喜者勿入。
  1. 既然是美劇就一定會因地制宜的進行某種程度上的改編,這是給看完韓劇,想看看美劇的提醒,順便一提,這也有改編日劇,不過我沒看就是了,我就不對這部分進行討論。
  2. 第一集開頭差不多,一個在車站,一個在機場,非常合理,美國比韓國大,用機場進行移動也蠻符合實情,中間稍微不同的是在刀子的橋段,再來最讓人意外的是,在第一次董事會結束後,因新聞報導後,韓劇理所當然地在第二集中,就被聘為醫生,但美劇中出現了第二次董事會,而主角也發表了演說,也非常符合主角的狀況的一段台詞,也就是這一段,讓我覺得改編的真是好啊!讓我有想繼續看下去的動力,不然,我原本還以為就只是照翻而已。這點我真的要給個讚!!!
  3. 再來是醫生人數,在韓劇有一大間,很多位醫生,但在美劇中一開始也才5位醫生而已,再加上美國輿情,也就是會有個膚色的醫生出現,這也對劇情產生極大的不同。
  4. 再來是醫生的角色上也有很大的不一樣,在日韓劇中,常常就會有類似丑角的醫生存在,但在本劇中,並沒有這樣的存在,各個醫生都是非常傑出的,沒有這種搞笑的存在。
  5. 主治醫生的couple依然還在,但發展跟美劇上有很大的不一樣。
  6. 主角哥哥的死亡方式也是非常不同的。
  7. 因兩邊集數不相同,一個20,一個13,可能在劇情的進展會不太一樣,美劇的主角父母劇情尚未出現。
  8. 韓劇主角是與醫生產生愛情,但美劇中則是與局外人產生愛情,這點也會非常不一樣。
  9. 一樣有看到長的與哥哥一樣的臉孔出現。
  10. 監護人與主角間的劇情,沒有太多的回憶,基本上都是現在的時間點進行,這點也是非常不同。
  11. 或許一開始有點針對,但隨著主角能力不斷展現,其實整季下來,霸凌的事件幾乎沒有,主角很快就進入狀況,這或許跟美國的英雄主義有關吧,只要能力夠強,反觀韓劇中,幾乎都是霸凌直到後面幾集才挽回局勢,心情上當然是看美劇比較沒有壓力。
  12. 在韓劇中一開始很多壞人一搞事,但最後都被漂白了,但在美劇中反而沒有這樣的狀況,大家都是以自己的身分立場,做該做的事,沒有人是壞人,只有對的事或錯的事,僅此而已。
  13. 再來就是,片中的手術畫面真的是假到不行,也不知道會甚麼會這樣,很容易出戲,韓劇這部分就處理得不錯。
  14. 董事會成員各個都是高手,不像韓劇中的似乎就是來陪襯的。
  15. 韓劇主要是小兒外科醫生,但美劇中就是個外科醫生,也就是說在病人的呈現像略有不同。
  16. 院長真得換人了,這點在第二季中會有更不一樣的表現。
  17. 韓劇中通常是以主角為主線貫穿整集,但在美劇中通常是以兩條主線來進行,一組有主角,一組沒有主角,來看彼此角色的互動,韓劇比較注重在主角與其他角色的互動上,這或許也跟醫生人數有關吧。
  18. 美劇中,醫生角色進進出出,而韓劇中,一直都是那一群醫生,沒有不好,只是呈現的方式會有所不同。



2018年9月23日 星期日

短網址QR Code APP

Date: 20180923
Version: 1

會想要做這個原因在於,現在公司的短網址和QR Code都是使用goo.gl的服務產生,但該服務於明年就會結束了,所以才在想要如何繼續下去。

會分成兩塊,一個短網址,一個QR Code,有的單位需要短網址,但另一個單位需要QR Code,而需要QR Code的那個單位會需要先行產生後,等相關內容確定後才會放上去正稿,因此會使用官網伺服器進行跳轉的方式,來達成動態連結的效果。

雖然如此,後來想想雖然有的單位需要短網址,但如果是用我的方法話,不就每次都要在官網建立跳轉嗎?很明顯是個浪費人力的方法,但既然都做了,還是紀錄一下好了。

QR Code
比較簡單,因為先前那一個加密的APP已經做過了,這次只是再把方法寫出來一次。

短網址
使用的方法是方法一[1],因為方法二我看不懂,所以採用方法一,十進位轉為XX進位法,所以你需要兩個東西,十進位,XX進位,XX進位目前選用的是58進位法,格式為大寫小寫數字[2],刪除容易讓人搞混的大寫O和零0,以及大寫I和小寫l,這四個在APP上的呈現容易令人疑惑,故刪除。

而十進位的來源,需為主鍵[1],也就是不會重複的一串數字,而有甚麼數字是不會重複的呢?我選擇的是時間,年月日時分秒,六個節段,時間是唯一的,不會有時間重複到,因此進行的第一次轉換,轉換過程主要是將十進位/58得商和餘[3],保留餘數,繼續將商/58德商'和餘',直到最後商<58,無法再進行除法,將最後商及過程得到的餘數,由後往前進行轉換為58進位法,就會得到一串簡碼,也就是短網址。

但在進行的過程中,發現年月日時分不太會變化,導致最後出現的簡碼,前幾個字串都幾乎一樣,後來我將得到的時間字串反轉,由後往前排,這樣的話,整個時間就會很常變動,因為秒數常變,導致除法得到的結果都不盡相同,例如: 20180923173717-->71737132908102,這個技巧還可以用在製作隨機種子時可以使用。

最後就是將得到的短網址做成QR Code而已,但對於實際進行似乎沒甚麼幫助。

參考來源
1. 短網址(short URL)系統的原理及其實現
2. The Base16, Base32, and Base64 Data Encodings
3. 二、八、十與十六進位 (數字系統) 轉換教學


2018年9月22日 星期六

桃捷的中秋晚會

Date: 20180922
Version: 1

20180920星期四,這一天是非常特別的,因為這一天是桃捷的中秋晚會,其實這活動去年也辦過,今年一樣照常舉行。

介紹一下活動內容,活動從四點開始,主要是園遊會的形式,再接著是烤肉。

園遊會是會有約30家廠商來,今年的園遊券有200元,比去年的100元好多了,100元買個兩樣就吃完了,還要自己掏錢,不過200元就不一樣了,可以吃得還不錯呢!而且重點是今年攤商的種類比去年好太多了,去年一大推重複,根本沒啥好吃的,今年有超多好吃的東西呢!

園遊會的地點跟去年一樣,今年主要是舞台換到員餐前面,還搭建了舞台,比去年好太多了,而烤肉區則在舞台前的廣場,去年則是在馬路中,跟園遊會的人潮擠在一起,超多人的,今年設計的比較好,還滿舒適的。

去年花完100元就閃了,也因為那天是司機員剛下班,吃完就回家了,今年是第一次參加資訊組的烤肉,所以逛完園遊會後,就回到資訊組的位子,開始烤肉了。

今年有舞台,當然就有舞台表演,還不錯,因為去年沒有待很晚,所以也不知道去年有沒有活動,再來就是晚上有抽獎活動,可想而知,我沒抽中,跟尾牙一樣,哀~~

最後,鄭文燦還出現來幫忙抽個市長獎呢,晚會結束後,一堆人獎券沒用完,就跑去買個不鏽鋼的餐具或是黑糖糕,比較可以帶回去的東西。

整體來說,比去年好玩很多,相關設計都很不錯,感謝總務處的支持,希望明年後年每一年都會繼續辦,而且辦的一年比一年好,感謝桃捷。

2018年9月16日 星期日

桌遊設定-3

Date: 20180905
Version: 1

主要是最近想把以前大學研究所做的桌遊重新翻出,除核心概念不變外,其餘應該都要大修特修了。

核心概念為,有1-9數字牌,三條或同花就可以換一顆星,集滿5顆就算贏了,但每一張數字牌都有其能力,能力可以對牌局產生各種影響,因此,到底是湊成牌組,還是使用能力?你要如何抉擇呢?

共54張,因式分解一下為: 2*3*3*3,可能做法如下:

  1. 2(重複)*9(數字1-9)*3(類型)
  2. 2(類型)*9(數字1-9)*3(重複)
目前是採用做法1,另外關於重複數及連續數,目前有以下組合: 
  1. 三重複 = 四連續 (機率差約1.5倍)
  2. 三重複+一顆星 = 三連續 (機率差約6.7倍,但6.7倍是否可以抵銷多一個星呢?)
  3. 兩重複 = 三連續 (機率差約1.8倍)
經考慮,三重複+一顆星=兩顆星,也就是說當湊齊三重複,就可以換到兩顆星,這收益是否過高,所以目前先暫訂作法1。

也考慮到五張牌要似連續又有點難,故可能改為作法2,但改為抽一張牌取代一顆星。

9種2重複,共有18張牌,因式分解為=2*3*3,故可分為以下四種組合:

  1. 9種能力,2重複
  2. 6種能力,3重複
  3. 3種能力,6重複
  4. 2種能力,9重複

目前會先以作法2為主,若idea夠多的話,會升級為作法1,考慮到有3種類型,故作法1會有27種能力,作法2會有18種能力,考量到能力太多容易混雜,故最後還是只做法2為主要考量。

後來在設計的過程中,發現18種能力實在太多了,玩家要在一場遊戲中記下18種能力真的不太可能,所以限縮之下,改為作法3,應該會比較可行吧!

三種類型分別為:攻擊牌(劍)、防禦牌(盾)和輔助牌(藥水),可參考獵人-貪婪之島-咒語卡片。
  1. 攻擊:對牌局產生作用,不論好壞,可參考犯人在跳舞。
    1. 抽牌: 從牌堆抽取一張。
    2. 左顧: 從一位玩家手牌中隨機挑選一張交換。
    3. 右盼: 。
  2. 防禦:預防/阻止攻擊效果。
    1. 禁止: 可取消一次之動作。(被動)
    2. 反射: 將該次攻擊返回原攻擊者。(被動)
    3. 轉移: 將該次攻擊對象改變為其他玩家,不含原攻擊者。(被動)
    4. 否定: 取消一次攻擊。(主動)
    5. 歸零: 棄掉所有手牌,直至下一回合前,不受其他牌影響,至下一回合時,將手牌補至上限。(主動)
    6. 同盟: 
  3. 輔助:可須配合其他牌使用,可能造成虧牌,故須有獎勵補償,可參考POE輔助技能。
    1. 擴散: 將單體效果轉變為全體效果。(範圍、次)
    2. Double: 將效果變為兩倍。(效果、次)
    3. 回收: 可回收其他玩家使用的牌,將該牌取回至手牌。(其他、主)
    4. 攤牌: 指定一名玩家,於下一回合前須公開展示手牌。(範圍、主)
    5. 無效: 消除輔助效果。(效果、主)
    6. 複製: 可複製自己手牌中的牌。(其他、次)
得分和出牌合併為一個動作,故出牌需一次出三張,然後這三張能力都會發動。
故三種能力要簡單化。
如果無得分和出牌,則蓋牌,並不會受到任何正負面影響,直到下一回合。(無敵模式)
如果得分和出牌一起使用,則無防禦相關等機制,不然一擋三的情況,太容易虧牌了。
因為沒有防禦,故攻擊能力盡量為不影響他人的牌數之能力。
其實還是可以保留影響他人手牌的能力,但需提供制衡的手段,例如: 可出4張或5張的牌型來阻止前一人出的牌型,並禁止其發動效果和換分,但作為代價,可換分,但一樣無法發動效果。
這邊就牽扯到牌型的組合數,來決定彼此的優先順序:

  1. 5張(max.)
    1. 順子:38,880
    2. 同花:54
  2. 4張
    1. 順子:349,920
    2. 同花:6,480
  3. 3張(min.)
    1. 順子:1,539,000
    2. 同花:203,040
依上述計算結果得知:5同 > 4同 > 5順 > 3同 > 4順 > 3順口訣:同>順,543,中間互換

  1. 攻擊(6種):
    1. 抽牌(3種):
      1. 好運:◎{一位玩家}從牌堆抽取※{一張牌}。
      2. 盜取:指定◎{一位玩家},抽取※{一張手牌}。
      3. 交換:與◎{一位玩家}交換※{一張手牌}。
    2. 棄牌(2種):
      1. 丟棄:指定◎{一位玩家},抽取※{一張手牌}捨棄。
      2. 宣告:宣告※{一個數字(9種數字,共6張)及一種顏色(6種顏色,共9張)}及◎{一位玩家},捨棄符合之手牌。
    3. 出牌(1種):
      1. 無效:本次連鎖卡牌效果無效化。
  2. 輔助(3種):
    1. 擴散:◎全體玩家。
    2. 增強:※效果加一。
    3. 複製:複製數字或效果。
基本上,卡牌效果如上所示,接下來就要開始設計版型。
版型將參考卡牌烹飪塔-頂級紙牌遊戲,但會於中間圖示下方增加描述字句/卡牌名稱。

卡牌為9*6.5公分,左上角為數字,三種顏色,數字1-9,右上角則是類型標記,共兩款,劍與藥水,代表攻擊與輔助,在中間會友符合該卡牌效果的造型圖示,最下方為卡牌效果描述。

大致上已設計完畢,之後就去找印刷機,印個彩色出來,再來試試看,到底規則這樣行不行。


  1. 20180917,4人,5/4/4/3,第二輪(牌庫空了算一輪)結束。
    • 鼓勵蓋其他人牌之情況,可獲得前人的分數,前人則無法獲得。
    • 每回合開始抽兩張牌。
    • 若本回合未出牌,則於回合結束前抽一張牌。
    • 每次玩家出牌後,其餘玩家依序確認是否蓋牌。
    • 當被蓋牌時,由蓋牌玩家開始下一回合。
    • 先達成5分者贏。
  2. 20180918,3人,5/2/0,第一輪就結束了。
    • 很容易空場,某一回合大家都在抽三張牌。
    • 也真的有人很衰到連3順都湊不出來。
    • 蓋牌情況還是很少出現。
    • 出3張以上的狀況也很少。
    • 由蓋牌者開始下一回合,感覺有點強。



圖片來源:
https://game-icons.net/

2018年9月8日 星期六

伊藤潤二絕命逃走中特展臺灣站
時間:7/14~9/16
地點:新光三越台北信義新天地A9 9F宴會展演館 (台北市信義區松壽路9號)

Date: 20180908
Version: 1

伊藤潤二的鬼屋

總共有AB兩館,也就是兩個鬼屋可以玩,但需抽號碼牌,地點是在A9一樓旁的小木屋,換完號碼牌後,來到A9 9F,進場後工作人員會先請放置物品,有置物櫃,但很暗,請開手電筒使用,貴重物品請帶在身上。

接下來有AB兩館可以看,就看哪邊比較少人,工作人員就會幫你排哪邊,只是我覺得抽號碼牌沒啥意義,也沒看工作人員有在看,主要都是看票後,將票根還你。

接下來就是排隊進場了,我去的時候大約2點多,跟同學和學姊去,共三人,人其實還好,算了一下,每一館大約耗時30分鐘,所以其實還好,但當我們玩玩出來時,超多人了,那時大概34點吧,所以要玩得請早,比較不需要排隊。

接下來就準備進入正題,也就是鬼屋的部分,每次可進入10人,進入後會有一個小房間,要進行事前宣導與準備,10人倆倆一排,工作人員會發一條繩索,會請所有人在鬼屋中都要抓著,並且請勿攻擊工作人員...等宣導語句。

接著就開始進入了,兩邊鬼屋除內容不一樣外,其實本質沒有差太多,所以我就概略的講一下,進入後應該跟大部分鬼屋差不多,會有人突然跑出來嚇你,平均大概有5個嚇人的點左右,整場進行的節奏都是由第一個人來決定,所以AB館,有一組就走得很快,有一組就走得很慢,而且如果想被嚇的話,就請排第一個,最容易被嚇到的,像我們兩次就排在中間,所以中間以後,其實看不太到前面到底發生了甚麼事,只知道前面開始嚇人了,要注意一下,所以已經被預警了,就不太會被嚇到了,另外帶著理智去看,也不太會被嚇到,另外有一個點,因為AB館同一個場域不同路線,所以有時候是會被隔壁館的聲音嚇到。

當鬼屋走完後,繩子會收回去,會請一個人接著一個人進入,這時候大家都以為是個人鬼屋,其實就只是個走廊而已,會通道伊藤潤二的展覽區,會展示一些伊藤潤二漫畫中出現的物品,再接下來就是紀念品區了,這是每一個展覽都會有的,基本上以上就是整個伊藤潤二鬼屋的過程。

說一下心得,發現其他人為啥可以叫的這麼大聲,有這麼恐怖嗎?基本上你都知道這是假的,只要有做好心理建設,知道會有人突然出現嚇你,應該就還好吧,整體而言,鬼屋是滿好玩的,但其實伊藤潤二的東西沒有想像的那麼多,說實在的,我還是比較喜歡看展覽,就像上一次的伊藤潤二特展,希望下次可做成伊藤潤二解謎逃走的樣式,應該會更好玩吧。

2018年9月2日 星期日

白色力量4:光榮城市-柯文哲的進步價值
                                                           柯文哲

Date: 20180902
Version: 1

柯文哲的第四本書

出的時間是在選舉前出的,很明顯是要宣傳柯文哲這四年來的政績,這本書重頭到尾主要都是在講柯文哲四年來做過甚麼事情,就我個人而言,我還蠻喜歡柯文哲的,至少不向其他候選人會去抹黑別人,通常都是別人來抹黑。

對於柯文哲競選連任這一件事,也是對台北市民的一種考驗,對於第一次是因為反對而選擇了柯文哲,在經過四年後,其表現是否符合市民的期待,會讓市民認為不後悔四年前選了柯文哲呢?

個人對於柯文哲連任是蠻看好的,但來看看未來該怎麼進行呢?先不論是否連任,有人說之後可以出來選總統,我覺得言之過早,我反而認為柯文哲可以將台灣六都挑幾個來選舉,來看看究竟會發生甚麼事?北部已經有了,剩下在中南在各挑一個,希望柯文哲可以將其風氣帶給其他城市,再接下來的事更有趣的,回頭去選台北市長,看看經過其他黨派的市長的任期後,台北市政府的風氣會不會又變成之前的那種樣子呢?

接下來就來看看選舉結果吧!

延伸閱讀
  1. 白色力量
  2. 白色力量2:改變成真
  3. 白色力量3:柯P模式

2018年8月24日 星期五

小說背景設定-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. 教育部國語辭典公眾授權網

2018年8月23日 星期四

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

Date: 20180818
Version: 1

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

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

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

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

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

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

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

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

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

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

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

Date: 20180809
Version: 1

介紹人類歷史

人類歷史科普書籍

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

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

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

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

2018年8月18日 星期六

桃捷資訊組二三事

Date: 20180809
Version: 1

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

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

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

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

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

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

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

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

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

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

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


2018年5月27日 星期日

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

Date: 20180527
Version: 1

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

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







2018年4月16日 星期一

排班管理系統

Date: 20180415
Version: 1

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

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

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

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

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

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

排班
交換
審核
公布

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

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

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

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


















2018年4月15日 星期日

桃捷公司內部招考

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%了。

2018年4月10日 星期二

桃捷資訊組的二三事

Date: 20180410
Version: 1

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

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

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

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

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

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

2018年3月21日 星期三

桃捷時刻表(簡易版)

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時就不會造成讀取錯誤。



2018年3月18日 星期日

桃捷司機員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部分處理好後,才會接下去,到時候可能就會再開一個新的文章了。

2018年1月12日 星期五

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。

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

2018年1月1日 星期一

桌遊設定-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。

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


種族特色:




2017年12月10日 星期日

關於大數據的二三事

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月) 到時候再補充電影小說有什麼不一樣。