跳到主要內容

千年一遇

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

搜尋此網誌

其他資訊

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

目前顯示的是 2月, 2016的文章

發表文章

TestNG筆記(4)Test Case執行順序

張貼者：藍月日期： 2月 17, 2016

+

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

Google Cloud Test Lab初探

張貼者：藍月日期： 2月 15, 2016

軟體測試 test

+

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

Java Database Helper效能比較

張貼者：藍月日期： 2月 11, 2016

database Java Web

+

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

Java Template Engine 效能比較

張貼者：藍月日期： 2月 09, 2016

Java Web

+

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

Oracle Mobile Application Framework使用心得

張貼者：藍月日期： 2月 04, 2016

MAF

+

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

其他連結

FB技術策展粉絲團

封存

2024 1
- 2月 1

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
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
讀書心得24
Android23
Dart18
test18
人生14
程式觀念14
職涯13
給那個人12
Android筆記11

顯示更多顯示較少

檢舉濫用情形

RSS訂閱

發表文章

發表文章

所有留言

所有留言

熱門文章

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

Cluster和HA的差別

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

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

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

我們真的需要為了宣告式UI而重寫App嗎?以Flutter與Android觀點討論

參考Flutter文件 Start thinking declaratively 最近在Google的推廣之下Flutter受到愈來愈多人的注意，而Flutter的UI Layout方式，官方稱之為宣告式UI靈感來自於React 猜想其核心概念是來自於函數式程式設計。然後根據我前一陣子使用Flutter來做Side Project的感想，宣告式UI就是在元件(Widget)之中撰寫對不同資料或狀態的顯示邏輯，所以當資料或狀態改變的時候，我們就不需要特地在去改變UI而是UI會自動更新，又或者是說與資料或狀態綁定的元件(Widget)，會重新被建立，這時UI的顯示規則就會照原先已經宣告好的顯示邏輯去顯示了，這樣就是所謂的宣告式UI。那麼這樣的做法替我們帶來了甚麼好處呢?首先UI對應資料或狀態的處理邏輯全部會被包在同一個元件(Widget)之中，未來要調整或觀看邏輯只要看元件(Widget)裏的宣告就能了解，再來也不會有命令式程式設計那樣改變UI的語法散落各地，在追蹤程式碼時還需要了解脈絡或是順序。所以聽起來真得很棒?我們應該趕快擁抱宣告式UI?雖然Android跟iOS都大力的擁抱了宣告式UI(Android => Jetpack Compose . iOS => SwiftUI )但是其實宣告式UI並沒真的好到要特地重寫的地步，其實React最早也說過自己要解決的問題是狀態龐大且複雜的UI問題，但大部分的App在現代框架架構分明的狀況下，要搞到架構龐大且複雜到不可維護的狀況，我自己是覺得蠻困難的啦。而在Android要依照資料或狀態頻繁更新的場景，也有Adapter這個模式扛起了類似宣告式UI的責任，而命令式通常也是用在更新比較沒那麼頻繁的部分，在加上現代強大的IDE要找到相對應的程式碼也沒有這麼困難。另外如果在Android有客製過View其實就知道，View本身就像是StatefulWidget是會保留著狀態，在資料更新時透過命令再去更新，其實跟Flutter要另外下setState()有點類似，但時間點不同，結果Flutter也是要為了這個setState()付出代價，需要各種狀態管理來達成更好的狀態維護與更新效率，當然大部分的App不會遇到就是，但也是會被潮流推著去使用，這邊也感覺的出為了解決一個問題，卻要解決更多衍生出來的問題，但終究

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 更

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還是有一段差距的，總之自己未來練習專案

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

BDD JBehave教學(1)使用心得

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

Java BDD測試框架選擇

BDD behavior-driven development 行為驅動開發，是一種將規格對應到程式行為，再結合測試，達到保護(驗收)業務邏輯的一種開發思維，現在也有很多框架協助大家更容易的上手BDD，目前是物色到 jbehave 與 Cucumber 來嘗試，雖然關鍵字驅動的 Robot Framework 更吸引我，不過目前還是先從jbehave玩起吧，cucumber找得到的入門資料較多，如果您有任何心得與經驗也歡迎與我交流。

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

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

技術提供：Blogger