跳到主要內容

千年一遇

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

搜尋此網誌

其他資訊

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

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

發表文章

Full Stack與DevOps的美麗與哀愁

張貼者：藍月日期： 8月 14, 2016

+

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

Java將死?

張貼者：藍月日期： 8月 06, 2016

Java

+

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

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 更

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不會遇到就是，但也是會被潮流推著去使用，這邊也感覺的出為了解決一個問題，卻要解決更多衍生出來的問題，但終究

Dart的async/await理解筆記

非同步寫法中期待已久的語法，可以脫離有些人詬病的callback hell，有興趣的人可以試著拿掉我範例中的await去體會執行順序的改變，async語法其實就是表示這裡是個非同步方法，其中的await就是表示要等這個方法執行完，才會繼續執行後面的方法，是不是用很簡單的寫法，就完成過去要管理順序與執行緒的麻煩事呢！相關資源 https://www.dartlang.org/guides/language/language-tour#asynchrony-support https://dartpad.dartlang.org/dc3b364fb7d7e793ff9d1964e078a663

Java Template Engine 效能比較

看資料的時候看到 template benchmark ，雖然個人也蠻喜歡 Thymeleaf 的想法，比較接近html設計師可以直接做，但效能真的頗糟，而現在漸漸走向前後端分離，這樣的技術還有需求嗎? Freemarker 還蠻常看到的，但效能超好的前三名居然聽都沒聽過，是說在玩的Vertx也沒支援就是Orz Rythm 靈感來自Razor跟PlayFramework一樣 stringtemplate 待研究延伸閱讀 Demo project to show different Java templating engines in combination with Spring MVC

in桌遊雜誌7閱讀心得

這集會讓我想買的原因就是送了一個看起來很棒的微桌遊gods move，是一個嘴砲陣營微桌遊這集比較喜歡的部分是，介紹一些旅行桌遊，不過比較特別的是介紹的桌遊是縮小版或易攜帶版，沒介紹本來就很好攜帶，也很好開場的微桌遊妙語說書人也是我很喜歡的桌遊之一，感覺很適合然來當做團隊互相認識與了解的桌遊，新桌遊介紹也很不錯，讓我發現原來還有很多很有特色的桌遊，設計師專訪也蠻激勵人心，是說設計師好多遊戲看起來都不錯阿再來說說雜誌缺點，看到一個錯字，跟一兩個缺字，希望未來能改進，不過做雜誌也是很辛苦的，希望喜歡桌遊的大家，能多多購買給予鼓勵簡單說明一下這次贈送的gods move,是個只有16張牌的微桌遊，雖然牌不多但卻能讓4到7人一起同樂，讓小偷老大可以指定一個人說誰是警察與為什麼的設定，真是讓嘴砲發揮可以好好發揮的好階段，雖然目前還沒實際試玩，但感覺起來就很有趣阿！

知識魔咒

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

Appium簡單介紹

去年聽到朋友介紹時，就跑去玩了一下，感覺還不錯，官方文件也很清楚，照著做就可以入門了，後來因為不是專門做測試的就沒有持續研究，最近看到 AWS有雲端測試服務後，又開始想玩了起來，不過要做的事很多，時間卻很少，一步步來吧，因為朋友說你覺得簡單，是因為你懂了，我們不懂的人，要看文件阿，要入門很難，所以我之後的練習都會盡量記錄起來，讓其他有興趣的人可以更容易的入門。

技術提供：Blogger