跳到主要內容

千年一遇

行動是通往夢想的捷徑，習慣是每天的行動。你若喜歡自己的價值，你就得給這個世界創造價值！

搜尋此網誌

其他資訊

Blog
資深軟體工程師的自我修練
挑戰測試101
Java Web Framework收集
技術廣播
Dart資源整理

目前顯示的是 6月, 2020的文章

發表文章

遷移Fabric Crashlytics 到 Firebase Crashlytics記錄

張貼者：藍月日期： 6月 29, 2020

Android Firebase

+

取得連結
Facebook
X
Pinterest
以電子郵件傳送
其他應用程式

不懂帶團隊，那就大家一起死！

張貼者：藍月日期： 6月 24, 2020

團隊管理讀書心得

+

取得連結
Facebook
X
Pinterest
以電子郵件傳送
其他應用程式

AndroidX 遷移記錄

張貼者：藍月日期： 6月 23, 2020

+

取得連結
Facebook
X
Pinterest
以電子郵件傳送
其他應用程式

從物件導向開始 (01)

張貼者：藍月日期： 6月 23, 2020

資深軟體工程師的自我修練

+

取得連結
Facebook
X
Pinterest
以電子郵件傳送
其他應用程式

其他連結

FB技術策展粉絲團

封存

2024 3
- 9月 1
- 6月 1
- 2月 1

2023 3
- 12月 1
- 10月 1
- 2月 1
2022 3
- 10月 1
- 9月 1
- 7月 1
2020 15
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

顯示更多顯示較少

標籤

軟體測試28
讀書心得25
Android23
Dart18
test18
人生14
程式觀念14
職涯13
給那個人12
Android筆記11

顯示更多顯示較少

檢舉濫用情形

RSS訂閱

發表文章

發表文章

所有留言

所有留言

熱門文章

Cluster和HA的差別

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

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

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

單元測試的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的概念)。這邊其實是為了克服，如果先寫產品程式，很容易就會遇到程式過度依賴環境或沒有採用依賴注入...等，造成的程式可測試性很差問題。最後很多定義或是原則，其實可以幫助我們學習跟理解，也有助於跟別人交流，但規則是死的，人是活的，有時候現實狀況，遇到跟教科書有衝突的問題，要學習著調整，最重要的事情是達成目的取得價值，而不是照課本上那樣做，別把自己束縛死，一頭撞死在牆上，希望大家看完這篇能有所學習，也歡迎交流。參考『無瑕的程式碼』一書

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

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

動態語言與靜態？直譯與編譯？強型別與弱型別？

(2021/06/18) 更新靜態語言的定義是能在編譯時期確認與檢查型別，在執行的時候不能改變結構，而動態語言則是在執行時確認與檢查型別，也能在執行時改變結構，例如:建立新方法或新屬性。舉個例子，使用某物件呼叫doSomething()，如果在編譯時就會告訴我們，這物件沒有doSomething()這方法，這就是靜態語言，如果到了執行時才發生沒有該方法的錯誤就是動態語言。靜態類型又分兩種，一種直接設定的是顯式類型如：String something = "something" 另一種透過類型推導的為隱式類型如：var something = "something" 後者的好處是在改變行型別不需要修改這個值傳遞過的所有方法，算是吸收了動態語言的優點，也保留靜態語言的型別檢查。而直譯與編譯就比較好理解，有透過編譯器跟只透過直譯器的差別，而通常有編譯器的多半是靜態語言而只有直譯器的多半都是動態語言，但為了滿足更多方向的需求，動態語言也會使用編譯器來編譯(速度優化、語言轉換需求)、靜態語言也會有使用直譯器來解釋的情形(REPL需求)。而弱型別與強型別又有什麼不同呢？強型別的語言會拒絕隱性的型別轉換如： var string = "3"; var number = 2 + string; 在Java中就會顯示錯誤而在弱型別的JavaSctipt中就會顯示23，它幫我們把2轉為字串了，雖然在這個例子當中，看起來這個功能好像很方便，但在實際開發中很容易遇到出乎意料的自動轉型所導致的程式錯誤，所以就易開發、可維護性這件事情上來說，我個人會偏好選擇靜態、強型別的語言來當作開發工具。參考弱类型、强类型、动态类型、静态类型语言的区别是什么？最後希望你帶走知識的同時，也能留下短短一兩句的心得與我們分享或是幫我們按下+1並分享到FB

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...

知識魔咒

知識魔咒也可以說是自以為是魔咒，也是文人相輕的主因，因為知識是很神奇的東西，你知道了就知道了，不論是自己發現還是別人告訴你，但如果你不知道，你就是不知道，甚至一輩子也不會發現，如果要自己去摸索，可能也要花不少時間，最後也不一定會找出答案。

Android 設定 Cucumber 實做 BDD 筆記

不了解BDD是什麼的朋友可以參考這篇，以前分享測試的時候有提到過這篇的脈絡是我想用Cucumber來驅動測試，透過Espresso + UI Automator + Mockito來做Client端的整合測試，定義的feature可以讓iOS拿去寫測試，又可以讓PM或是QA有個參考，更讓未來維護的人知道功能的脈絡。參考官方網站官方的專案是OK的可以跑，但要用在自己的專案上，要設定什麼就很難看出重點在哪裡了，所以導入花了一點時間，剛好可以記錄一下。在app的gradle中加入依賴 androidTestImplementation 'io.cucumber:cucumber-android:4.3.1' 在專案的package name(例如:com.example)底下新增一個test(例如:com.example.test)以上是指在androidTest底下，把官方範例中的CukeulatorAndroidJUnitRunner放在test裏，在app的gradle中加入 testApplicationId "com.example.test" testInstrumentationRunner 'com.example.test.CukeulatorAndroidJUnitRunner' features放在androidTest/assets/features底下記得去安裝plugin features檔的關鍵字也可以用中文寫執行測試透過gradle執行connectedCheck 如果實做行為的step檔想要另外放，如各自的package底下，要在CukeulatorAndroidJUnitRunner中加入glue設定，例如 @CucumberOptions ( features = { "features" } , strict = true, glue = { "com.example" }) public class CukeulatorAndroidJUnitRunner extends CucumberAndroidJUnitRunner 最後希望你帶走知識的同時，也能留下一兩句的心得...

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 更...

技術提供：Blogger