千年一遇

2023 3
- 12月 1
- 10月 1
- 2月 1
2022 3
- 10月 1
- 9月 1
- 7月 1
2020 15
- 12月 2
- 10月 1
- 9月 1
- 8月 2
- 7月 1
- 6月 4
- 5月 1
- 2月 3
2019 6
- 12月 1
- 11月 1
- 8月 1
- 7月 1
- 5月 1
- 4月 1
2018 28
- 10月 1
  - 台灣電子書選擇心得
- 9月 1
- 7月 2
- 6月 1
- 5月 2
- 4月 4
- 3月 2
- 2月 10
- 1月 5
2017 76
- 12月 4
- 11月 1
- 10月 6
- 9月 4
- 8月 4
- 7月 5
- 6月 21
- 5月 6
- 4月 8
- 3月 7
- 2月 6
- 1月 4
2016 61
- 12月 1
- 11月 2
- 9月 11
- 8月 2
- 7月 6
- 6月 7
- 5月 8
- 4月 6
- 3月 8
- 2月 5
- 1月 5
2015 39
- 12月 8
- 11月 7
- 10月 2
- 9月 9
- 8月 3
- 7月 6
- 4月 1
- 2月 2
- 1月 1
2014 4
- 12月 1
- 11月 1
- 5月 1
- 2月 1
2013 2
- 11月 1
- 10月 1
2012 1
- 2月 1

顯示更多顯示較少

flutter9
Java8
Switch8
愛的極白6
新聞碎碎念6
桌遊新世界6
Appium5
Web5
單元測試5
服務/產品心得5
遊戲5
Angular Dart4
BDD4
Vertx4
testNG4
管理4
電影思考4
Angular Dart 筆記3
Espresso3
GWT3
J2ObjC3
Kotlin3
unit test3
公司3
團隊管理3
罰單申訴3
資訊技術3
跨平台3
AWS Device Farm2
Angular2
Firebase2
Gradle2
Ionic2
JBehave2
JMockit2
database2
weka2
壘球2
翻譯2
蝸牛需要梗2
軟體工程2
Android Studio1
Android Tool1
CSS1
ChromeApp1
Cordova1
Cucumber1
Design Patterns1
JDBC1
JavaScript1
Junit1
MAF1
Mockito1
Mystory1
Play1
R1
React1
React Native1
Server1
TDD1
TypeScript1
UIAutomator1
google1
maven1
sqlite1
上與下之間1
占卜1
城市與鹽的故事1
壘球魂1
如果我有間公司1
安全性1
工程師的故事1
敗家日記1
文章材料1
易經1
機器學習1
溝通學學溝通1
王者之道1
環境變數1
產品製作1
程式1
經典名言1
自我成長1
蚊學1
行銷1
設計模式1
資料庫(Database)1
資料探勘1
資深軟體工程師的自我修練1
部落格規定1
青鳥的尾巴1
食記1

顯示更多顯示較少

RSS訂閱

發表文章

Atom

發表文章

所有留言

Atom

所有留言

Cluster和HA的差別

Cluster跟HA好像很類似，常聽人家在講好像一樣，又不一樣，所以就找了些文章來釐清這些概念，下面這篇其實講的蠻清楚的。

前情提要 Java BDD 測試框架選擇 JBehave較老牌，功能較多，甚至支援Gherkin (Cucumber所使用)語法，也就是原本使用Cucumber的也可以輕鬆跳槽JBehave，搶人意味濃厚，其實JBehave簡單好用，可是官方很多小細節的處理，處理的不好，導致一開始讓人覺得門檻很高，如官方範例中沒有簡單的起手project，然後 TestNG的範例只是示範用法，而且還有問題Orz，導致在玩的過程差點放棄。

Switch 我的實況野球2020手把解決方案

從PS2時代就是實況野球的狂熱者，雖然有一堆遊戲但有空的時候還是只開實況野球起來玩，經過了好久沒玩遊戲的歲月，在幾年前入手了Switch，而今年終於等到了實況野球2020這個完整作品，2019這個黑歷史我們就不談了。喜歡打比賽的我終於可以在線上直接配對比賽了，之前2019還要自己成立社群約比賽，還分日、亞板不能互連，導致找了一堆人最後可能還是不能對戰的困擾，在這版本終於解決了。原本玩格鬥遊戲都是用F310( 參考之前文章 )，其他類型的遊戲都使用Joy-Con，但Joy-Con飄移非常嚴重，噴了電子節點清潔劑雖然有用，但實況野球對於準確度的要求非常高，有些球強振可能是全壘打，用了Joy-Con就剩下鳥飛而已，因為對實況野球的熱愛，以及對Switch Pro手把的疑慮，於是就產生了這篇文章，到底在Switch上有沒有什麼適合拿來打實況野球的手把呢?我比較了Joy-Con、F310、Switch Pro、DS4(PS4手把)，以下就讓我一一來分析。 Joy-Con Joy-Con的香菇頭在用過DS4跟Switch Pro，就能夠很明顯感受到拿來玩實況野球比較不適合，如果DS4或Switch Pro的磨菇頭從靜止不動的正中間向左或向右推到底是100的話，Joy-Con大概就只能推到40~50左右的距離，所以就變成移動投球點或是打擊框的敏感度更高更難操控，當然如果是外出朋友分著玩還可以，如果是自己打線上杯賽就比較不建議使用，況且我自己還有放掉無法置中，按上放掉後有時還會自己往上飄移的問題。 F310 是我的格鬥用手把，這次剛好拿來測試實況野球，結論是完全不堪使用，F310的磨菇頭無法做到細緻的移動與判斷，完全不建議使用，也有PTT的朋友表示一些副廠手把也是這樣，所以想買副廠手把來打實況的可能也要注意一下。 Switch Pro 跟朋友借來的Switch Pro感覺蠻新的，一入手的確如同很多人所說的握起來手感很舒服，但缺點就是R、L鍵太軟我不喜歡，然後R鍵有微微的接觸不良，朋友的這隻Switch Pro沒有飄移的問題，對於失投的紅中球可以輕鬆的扛出去，磨菇頭的移動非常滑順與靈敏，但因為磨菇頭的阻力太小再加上很靈敏，可能會發生非有意識的偏移，如:右手按鍵太大力、身體的微動都可能讓磨菇頭動到影響打擊框，有點像在開槍你要控制好呼吸再慢慢扣下板機的感覺XD DS4(PS4手把

Flutter放棄了MVC概念的好與不好?

先說明這邊指的MVC概念，如果是Web開發者，View的部分是獨立出來的html然後再由javascript這邊自己去劃分Model跟Controller，而Android這邊也是有將View獨立出一個xml的概念。這樣個區分方式最大的優點就是可以讓UI設計跟程式開發分工合作，UI設計將定案的設計稿寫成html跟css，後續再交給程式設計師串資料或加動畫，也是很美好的願景。但現實上我看到的狀況，大部分的UI設計師都只是平面設計，甚至對Web跟App沒什麼概念，他們只負責聽PM的規劃做設計稿，然後幫程式設計師切圖，UI的layout到資料串接、業務邏輯...等，都是程式設計師一手包辦，只有少部分有sense的公司會把UI的責任真正交還給UI設計，當然這很大的部分還是跟人才訓練有關。另一方面在Android的好處還有透過xml去layout可以透過Perview看到靜態的畫面，加快調整的速度(跟用程式碼組View相比)，再來xml就像是UI模板，在其他的功能如果遇到一樣的layout就可以重複使用。 Android layout的方式 Flutter這邊，因為靈感是來自於React，所以也是放棄MVC模式用程式碼的方式去組UI(也有人說這是DSL[Domain-specific language])，但如果React覺得這種方式好為什麼又有JSX呢?如果覺得用程式碼組UI方式不好那為何又採用那種方式呢?這邊我就不太懂了。當時覺得React跟React Native的抽象UI層的概念很棒，但遲遲不進去玩的點就是因為是使用JavaScript這個語言，跟有一些感覺是為了新潮而新潮的東西ex:Flux(我還無法體會單向資料流的美好)，當然這些有可能是因為使用JavaScript的關係所以需要用這樣的東西來做專案會比較好維護。記得之前看過網友說，web界花了十幾年的時間才讓view跟程式分開，而React只花了一年就把它打回原形了，為什麼採用這樣的模式？我會覺得以框架開發者的角度，這樣做一開始的時候會輕鬆很多，但實際上的原因可能就只有作者才知道了，看到一些資訊是因為React是移植Facebook內部的另外一套框架而來，所以可能是那套框架就是這樣設計的吧。 flutter layout的方式而Flutter是使用Dart

單元測試的F.I.R.S.T原則(F.I.R.S.T Principles of Unit Testing)

剛好有網友提問，測試第三方API是不是單元測試(Unit Test)，正好順便寫這邊紀錄一下，我的理解是，不是，這比較偏向整合測試(Integration Test)，因為測試API依賴了，網路、Server、database所以我將它認定為整合測試，單元測試我的認知是一個class的測試，而根據我自己學習軟體測試的經驗，單元測試的發展方向是往開發的輔助工具去走，在更改程式時，可以藉由更快速的單元測試，來發現改壞或未符合需求(TDD)的問題，所以才會有FIRST原則。 First 快速測試如果跑得不夠快，就不會讓人想常常跑，不常跑的測試最後也就失去的它意義了。所以實務上會使用mock工具，mock其他依賴的物件或環境，來加速測試的執行。 Independent 獨立測試要相互獨立，一個測試不會依賴其他測試，如果互相依賴的話，一個測試的失敗會影響其他測試也跟著失敗，那麼在找問題點的時候將會變得更困難。 Repeatable 可重複測試應該要可以在任何環境中重複執行。減少因環境因素而產生測試失敗的問題。 Self-Validating 自我驗證測試程式應該要輸出布林值。不管是測試成功或失敗。簡單來說就是可以在測試報告很清楚的看到紅燈(測試失敗)或綠燈(測試成功)。 Timely 及時撰寫測試要及時，最好是在寫產品程式前先寫(TDD的概念)。這邊其實是為了克服，如果先寫產品程式，很容易就會遇到程式過度依賴環境或沒有採用依賴注入...等，造成的程式可測試性很差問題。最後很多定義或是原則，其實可以幫助我們學習跟理解，也有助於跟別人交流，但規則是死的，人是活的，有時候現實狀況，遇到跟教科書有衝突的問題，要學習著調整，最重要的事情是達成目的取得價值，而不是照課本上那樣做，別把自己束縛死，一頭撞死在牆上，希望大家看完這篇能有所學習，也歡迎交流。參考『無瑕的程式碼』一書

闖紅燈罰單申訴紀錄(中)

在等待判決結果的同時，來跟大家分享，如何免出門，在家完成行政訴訟。 (來源: 違規單(紅單)申訴流程-交通部公路總局-高雄區監理所 ) 申訴 => 線上機制可以到監理服務網 - 意見信箱暨申訴平台提出申訴，我自己因為在高雄所以當初是在高雄市政府交通局，提出申訴。這邊要注意要提出明確有利於自己的證據，才有可能申訴成功，不然裁決所都只會回依法舉發，一切合法來駁回申訴，如果申訴失敗覺得打官司有勝算的話請往下一步驟。行政訴訟 => 線上機制起訴狀可參考司法院書狀參考範例，中的第35項可透過電子郵件的方式傳送，可參考行政訴訟文書傳送 - 電子傳送或參考這邊，記得要查一下法院的電子信箱，我寄的高雄地方法院為ksdemail@mail.judicial.gov.tw。那這樣線上提出訴訟，我該如何繳裁判費三百元呢?別擔心，當法院受理案子後會寄繳費通知單來要求你補繳費用(參考: 法院辦理訴訟事件多元化繳費作業注意事項與最新消息-《訴訟》修正「法院辦理訴訟事件多元化繳費作業注意事項」 )，而這邊的繳費也是可以透過線上轉帳來完成。以上就完成了如何線上申訴，免出門一條龍服務目前已經我的案子已經到了證據調查，估計如果沒證據證明我闖紅燈，應該就會勝訴吧?

Switch 我的格鬥手把解決方案

從以前就熱愛格鬥遊戲的我，其實對於使用Joy-Con的香菇頭來轉招式覺得非常的不習慣，加上令人詬病的飄移問題，不管是打七龍珠FZ還是大亂鬥在有些細節的操作上都不是這麼的順手，聽說Switch Pro手把的手感會好一些，但似乎也有飄移的問題，也無法解決蘑菇頭的不習慣，所以開啟了我尋找自己的解決方案之路。首先香菇頭的問題，在找尋了眾多的方案之後，我看上了羅技的F310，當然最強手把公司的 Xbox one或PS4手把我也有考慮過，畢竟牌子大通路多，也能夠保證有一定的品質與品牌壽命，壞了也很容易買到新的產品來取代，不會像一些白牌手把，可能壞了就再也買不到一樣的了。因為也有PC上的需求，所以能夠通用才是CP值高的最佳選擇，但如果選擇Xbox one的話以蘑菇頭為主要方向控制的問題還是沒解決，PS4雖然看起來不錯但比起F310的8向十字鍵來說在格鬥遊戲上就輸了一些，加上價格也是F310比較便宜，品牌跟通路來說羅技也不需要擔心！最讓我覺得可惜的是R2跟L2是扳機鍵型的按鈕，除了這點不滿意外F310真的是PC上超好用的手把，一些預設要使用蘑菇頭移動的遊戲，也能按下手把上的MODE按鈕來跟十字鍵交換，一秒改成十字鍵操作！那麼接下來的問題就是，要怎麼用在 Switch 上呢？我的方案是N100 Plus轉接器，他看起來是N100的下一代，價格一樣但多了藍芽功能！也就是說他可以將我們原本有線的F310變成無線手把，透過藍牙連到Switch 上，立刻讓F310進化成無線手把！但要注意的是N100 Plus本身並沒有電池，所以還是要透過USB插頭或隨身電源供電！分享一下幾個我自己常用的模式 1.直接插在Switch TV模式的USB孔 2.使用藍牙模式連結Switch 驚喜的是它還可以 3.使用藍牙模式連結PC 透過這個模式就可以發現，N100 plus就是把透過他連結的手把轉換成 Switch Pro，最棒的是上面提到的MODE功能還是能夠使用，所以透過十字鍵在Switch上打大亂鬥也絕對不是問題，當然XboX手把跟PS4手把都能轉接，只是我個人更喜歡F310的高CP值，自己這樣搭配下來費用一千有找，可以痛快的玩格鬥遊戲又不用被會飄移的蘑菇頭所折磨，真是讓人感到身心舒暢，你又是怎麼搭配自己的手把呢？歡迎跟我們分享～ 2019/10/08 更

Windows跑Appium以aws device farm sample為例

這邊假設大家已經設定好環境需求裝好Android(要設定ANDROID_HOME環境變數) 裝好 Appium 裝好Git

Google io 2017

主軸雖然是Google推出的AI相關服務，但我自己的焦點還是放在Android跟Flutter，Android的部分這次有支援的新語言Kotlin，如果之前沒玩過Scala我應該也會很瘋狂，但是有玩過就覺得還好，雖然他比Scala好上手，不同語言的學習還是有它的成本的，但長期來說我是看好Kotlin的，我的觀點是因為Java太穩定太無聊了，所以需要一些新東西，而Kotlin出現在這個時間點，剛好可以給沉悶已久的Java世界帶來一些新趣味，但Kotlin要真的強大起來可能要等，Kotlin to JavaScript跟Kotlin to Native補上，但是到那個時候說不定Flutter早就大紅大紫人們早就忘了Kotlin也不一定，當然也有可能情況是反過來啦XD。再來有興趣的點是 Instant App ，可能大家還不懂這是什麼，簡單來說它可以讓Android App變成跟Web一樣，只下載當時所呈現畫面功能所需要的模組，讓你馬上就可以試用功能，一樣是給對方一個連結就可以達成，而對方也不需要先去下載App，就是Web的擴散，但用起來的體驗卻是App，假設未來可以其他平台達成有多好，比較美中不足的是只有Chrome OS整合Android，如果Chrome也有整合Android的話，這整個跨平台帶起來會是多可怕的體驗啊？ Architecture Components 也值得一看，本質上就是以MVVM架構為底，補上一些更好用的Library，沒想到google會跳下來做這個。最後是重頭戲Flutter，這次的介紹讓我看清楚他真正的威力，基本上可以把它想像成cordova的模式（注意實作上有不同，這邊只是抽象概念），UI從用Web的做法變成用flutter的做法，而跟Android/iOS的互動就跟cordova一樣透過Plugin的方式去呼叫，這次介紹的範例，在選擇圖片或拍照的部分就是透過Plugin的方式在各自平台實作，沒了效能問題&只需要補通用Plugin這模式我個人覺得非常成功，因為他不像ReactNative，要共用View你就要兩邊一起實作，但View有很大的層面會需要客製化，要達成就要ReactNative跟Android/iOS能夠緊密合作才行，跟採用flutter/cordova還是有一段差距的，總之自己未來練習專案

闖紅燈罰單申訴紀錄(上)

前陣子被開了一張很讓人生氣的罰單，我是看到黃燈左轉，卻被警察攔下說我闖紅燈，而且完全不聽解釋，就說『我就是看到你闖紅燈，還想騙』，當下就覺得該員警已經無法與之溝通，決定要走申訴管道，後來經朋友提醒，發現該員警身上有吊了一個攝影機在胸前，可惜當時沒經驗，不然應該當下要求檢視錄影證據，後來蒐集很多資料時，都發現遇到不合理的開單，就要據理力爭，不然很多員警開單都是用錯誤的方式在取締，讓我想起多年前在台北被開的闖紅燈其實也可以申訴，這次想要增加申訴的經驗，未來有機會可以做個線上申訴機器人也不錯。

技術提供：Blogger