千年一遇

2025 2
- 12月 1
- 11月 1
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
- 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

顯示更多顯示較少

RSS訂閱

發表文章

Atom

發表文章

所有留言

Atom

所有留言

從以前就熱愛格鬥遊戲的我，其實對於使用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

Cluster和HA的差別

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

小米手環2代送修

嗯…剛過七天，心率檢測就壞掉了…比較奇怪的是慢跑的心率檢測可以，但單測心率就都會失敗，上官網查了一下，北中南都有維修站，不過那時間，一般上班族不太可能自己送修，好險有跟震旦合作，提供代客送修服務，不過要記得帶訂單編號，應該是水貨太多，要克制水貨的做法，比較值得注意的是，問了一下維修時間，店員居然說要兩個禮拜…兩個禮拜…兩個禮拜…，還說已經有收到四個手環送修了，所以會比較久，如果都是二代的話，那第一波搶到手環的人，感覺很像是白老鼠，當初第一代因為懶得搶，所以蠻後期才買的，用到現在都沒什麼問題，不知道是運氣問題呢？還是？後續維修服務如何讓我們拭目以待。 2016/09/22 朋友搶到第三波的手環，結果一測，心律也是壞的，就直接退貨了，還很不爽的說，到貨只要一天，退貨要二十天，被飢餓行銷控制的人，要買之前可能要再多加考慮 2016/10/12 結果官網上的維修進度根本不準，還是自己打到震旦門市，才跟我說已經修好了......據說是換了個新米粒給我，目前使用上沒有問題。

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

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

wit.ai與api.ai比較

因為自己在玩的時候，找不到中文資料，所以就自己簡單紀錄一下。 wit.ai被FaceBook收購，api.ai被Google收購，兩邊其實都有雄厚的靠山，一開始是因為前端入口打算使用FaceBook Message，所以選擇了wit.ai，雖然它整體的UI跟功能比api.ai好懂，但我後來還是選擇了api.ai，因為使用api.ai不用架Server，完全不需要碰程式，一分鐘之內就能整合好FaceBook Message，讓我們很快速的能專注在Bot的對話設定之中，雖然覺得未來wit.ai應該會高度整合FaceBook Message，達到類似api.ai設定填一填Bot就搞定了，但目前還沒有，所以現階段我還是會以試玩api.ai為主。參考資料 Chatbot 2: 低價製造chatbots的利器Wit.ai - https://goo.gl/vvuaVq

Dart的async/await理解筆記

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

我們與bug的距離

最近跟同事分享軟體測試的做法與工具同事提出一些問題引發我後續的思考 1.寫了測試可以幫我們找到bug 嗎？我回答測試比較像是保護程式不出現 bug ，因為程式寫完、測完之後就不會壞掉了，會出現問題通常都是在程式有變動，像是加入新需求或是需求變動的時候，而軟體測試就是要確保我們變動之後，之前的需求還是有被滿足，沒有產生bug。 2.另外一位同事提出，他以前公司曾用過monkey test 來找bug 。這兩個問題讓我開始思考，bug的定義是什麼？先不要看網路上的資料，先自己思考一次。不符合需求的是bug，那需求上沒寫的呢？會crash？這應該是大家都認可的bug 那跑版呢？這就要歸咎原因是多尺寸裝置或不同瀏覽器造成的，還是程式寫錯，如果是多尺寸裝置或不同瀏覽器這就是沒在需求中不是bug，而程式寫錯當然就是bug。以前我會覺得monkey test沒用，但隨著對各總不同工具的了解跟體會後，說沒用這個詞太重了，每個工具都有可能可以解決測試上的部分問題，只是%數多寡而已。之前朋友跟我分享他們家的測試很厲害，測試 Android 的SeekBar 可以測出bug 。那他是怎麼測出來的呢？據說是點著微抖動幾十秒之後會 crash ，然後他去看log是這個元件底層產生的錯誤。這樣也算bug嗎？這根本不符合一般使用狀況，這個案例就很灰色地帶了，因為他的確造成了crash 但這也不是在需求之內？就像做一臺電風扇，我們也只會測開關正不正常、有沒有風，比較看不見的就是電壓或是零件有沒有符合相關的安全規定，但應該不會有人把它拿去北極然後冷到轉不動說這臺電風扇有問題吧？但在軟體上就很難說了，因為軟體上的極端狀況不是大家都能理解的，上面那個例子就是極端狀況，而且大部分的使用者不會這樣使用，我不會覺得他是一個bug，大家認為呢？而我覺得monkey test 效果比較不好的點是，其實大部分的人期待monkey test做的是探索測試，但它做起來卻比較偏向壓力測試，而探索測試比較像沒有規格的手動測試，就是直接看畫面上有什麼去建立使用邏輯或者做不同邏輯的使用操作試試看會不會 crash 或是探索出一些規格上當初沒定到的需求或邏輯，這部分是我覺得很難用工具取代的部分，而規格上有的邏輯就可以使用軟體測試去驗証減少人力在回...

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

技術提供：Blogger