千年一遇

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

搜尋此網誌

其他資訊

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

目前顯示的是 4月, 2015的文章

顯示全部

發表文章

GWT初探心得

張貼者：藍月日期： 4月 18, 2015

GWT

+

0

取得連結
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
- 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
  - GWT初探心得
- 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

所有留言

(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

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

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 更

我們真的需要為了宣告式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 我的實況野球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手把

Dart的async/await理解筆記

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

Mobile軟體測試(2)為什麼要軟體測試?

前篇 Mobile軟體測試三十天(1)測試的美麗新世界介紹測試最重要的開場白!為什麼要寫測試，如果沒有痛點，或是痛點沒有被重視，就不要去推動寫測試，這是甚麼意思呢?意思就是價值導向，假設是金融業，今天系統一出包就有上級要被懲處，這時候用測試來解決問題的價值就高了，推動的可能性就會提升。

技術提供：Blogger