千年一遇

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

顯示更多顯示較少

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
設計模式1
財務自由攻略1
資料庫(Database)1
資料探勘1
資深軟體工程師的自我修練1
部落格規定1
青鳥的尾巴1
食記1

顯示更多顯示較少

RSS訂閱

發表文章

Atom

發表文章

所有留言

Atom

所有留言

重點寫在前面，網拍蝦皮上的Y字螺絲起子很多賣場都會寫Switch專用，但其實尺寸可能有所不同，第一次買了0.6的Y字螺絲起子，因為以前有把螺絲轉壞的經驗所以這次特別注意，但就算我已經很小心還是一直滑牙打不開，後來看了youtube上的影片後才了解滑牙多半不是技術問題，是工具問題！後來才又在別的賣場買了1.5的Y字螺絲起子後輕鬆的就打開了！所以選對工具非常重要！拆解過程可以參考 youtube影片，像我自己拆開後發現有不同的JoyCon結構大概是不同時期的結構改良，可以參考另一個影片，解決了螺絲起子跟拆解問題後就成功的將排線更換完畢了，料錢加工具大概200百有找，比起送修便宜不少，JoyCon的故障率感覺也不低，如果有能力自己試著修理一些網路上買得到料小問題也是能省下不少錢，大家在修理的時候有遇到什麼問題呢？歡迎跟我們分享。

單元測試的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原則。 Fast 快速測試如果跑得不夠快，就不會讓人想常常跑，不常跑的測試最後也就失去的它意義了。所以實務上會使用mock工具，mock其他依賴的物件或環境，來加速測試的執行。 Independent 獨立測試要相互獨立，一個測試不會依賴其他測試，如果互相依賴的話，一個測試的失敗會影響其他測試也跟著失敗，那麼在找問題點的時候將會變得更困難。 Repeatable 可重複測試應該要可以在任何環境中重複執行。減少因環境因素而產生測試失敗的問題。 Self-Validating 自我驗證測試程式應該要輸出布林值。不管是測試成功或失敗。簡單來說就是可以在測試報告很清楚的看到紅燈(測試失敗)或綠燈(測試成功)。 Timely 及時撰寫測試要及時，最好是在寫產品程式前先寫(TDD的概念)。這邊其實是為了克服，如果先寫產品程式，很容易就會遇到程式過度依賴環境或沒有採用依賴注入...等，造成的程式可測試性很差問題。最後很多定義或是原則，其實可以幫助我們學習跟理解，也有助於跟別人交流，但規則是死的，人是活的，有時候現實狀況，遇到跟教科書有衝突的問題，要學習著調整，最重要的事情是達成目的取得價值，而不是照課本上那樣做，別把自己束縛死，一頭撞死在牆上，希望大家看完這篇能有所學習，也歡迎交流。參考『無瑕的程式碼』一書

UI測試pattern Page Object 與 Page Factory

Page Object Pattern 就是將畫面上的功能抽象化為程式中的method，這樣做有甚麼好處?

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

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

桌遊星杯傳說十週年盒子收納分享

盒子本身可以完美收納就是舒服這篇主要是想分享，新版的星杯傳說十周年盒子變小了，雖然更好攜帶但裝好了牌套卻放不進去了，疑?那上面的圖片為什麼可以剛好收納?其實盒子的空間是的可以收納放上了牌套後的所有牌+配件，但卻被中間隔開空間的紙板吃掉了，只要將紙板拿起來將中間紙板上下用來撐空間的紙片交疊就可以留出放下的空間，再來把紙板左右兩片的紙板反摺，用盒子擋住左右邊的牌就好，完美的自收納就完成了(灑花最後希望你帶走知識的同時，也能留下一兩句的心得與我們分享或是幫我們按下+1並分享到FB

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

(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

BDD JBehave教學(1)使用心得

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

我到底需不需要學設計模式(Design Pattern)?

先說我的結論，要學，但可能用不到! 看了我的答案，有的人可能會覺得很矛盾，別急...先看完我的想法。物件導向核心就三件事: 封裝繼承多型而這三件事又能延伸出多項原則，來讓這三件事能發揮最大價值，這些原則分別是: SRP 單一職責原則 OCP 開放封閉原則 LSP Liskov 替換原則 ISP 介面隔離原則 DIP 依賴反向原則 LKP 最少知識原則如果用武術來形容軟體的概念，上面提到的就像是武功心法，用文字去描述武功的重點，輔助避免練功時練錯方向，而設計模式就像是武功中的招式，在招式中去體會心法，心法幫你練成更棒的招式。所以如果想體會物件導向，就需要透過學習設計模式去體會封裝、繼承、多型是要怎麼應用，又為什麼要衍伸出多項原則。其實它們的核心都只有一個，就是為了『替換(修改)』，當然如果可以，學習軟體測試也是其中一環。至於為什麼會用不到?因為很多框架都實作了設計模式，所以如果你用的框架說自己很靈活、很好修改，那他一定用了很多設計模式在裡面，像Spring、Android等，裡面處處都可以看到設計模式的蹤影。所以如果不是自己設計框架，通常...不會用到設計模式。那....我們就不用學嗎?當然不是，開頭的結論就說了，要學!它會讓你知道封裝、繼承、多型的重要性，讓你在寫程式的時候將這些放進你的程式與思考之中，再者雖然設計模式不常用，但一旦用到，它會產生非常高的價值! 有看過一些反對設計模式的說法是，設計模式是毒瘤，拖慢了我們整個專案，把一件小小的事情搞得很複雜。對於這類的說法，我只能說，也許他們的看法是對的，那你們幹嘛硬套設計模式呢?通常會遇到這種狀況的，我都覺得是"教科書症候群"，就是指教科書上怎寫，它們就不思考到底有沒有效益，只會說教科書就是這樣寫!一定要這樣做才是正確!最後被虐千百次之後，憤怒的將教科書砸在地上，大罵"此書誤我人生"。舉個生活中的例子，就像你只是想走到巷口便利商店買瓶飲料，走路大概只需要五分鐘，你也可以騎機車或開車，但你硬要選開車，只因為汽車最快、最安全，然後出車庫找車位卻花了十分鐘以上，然後來抱怨說汽車不好類似。最後總結一下，學設計模式可以讓你對物件導向的概念更清楚，而當你...

從物件導向開始 (01)

一開始在學習Java的時候，老師都會說物件導向這個詞，不曉得大家的老師是怎麼告訴大家物件導向是什麼的呢？用我多年來的經驗來說就是人類所理解領域的對映或者說是抽象對沒經驗或不理解的人來說這句話可能很難懂，可以先想想大部分我們寫程式都是為了完成一個需求，而這個需求通常是本來就存在於世界上，但現在要用程式來處理它，為了程式的架構與理解可以更加容易，我們通常會用現實生活的概念去對映程式，比如班級資料，就會有學生跟老師，那我們就可以對映到程式世界中會有個老師物件與學生物件，這樣子我們就能很快速的理解，原來這程式是在描述我們世界中班級的概念，有了這樣的領域概念後不論是在設計或是理解上都會容易很多，我想這也是物件導向被推崇的原因，程式的好理解與好維護就是一個工程師需要不斷自我追求的目標。物件導向中的三個核心封裝、繼承、多型繼承在現代程式開發中已漸漸被淘汰了，新的概念是用組合替代繼承而封裝與多型就是物件導向可以在嚴謹的架構之中又能靈活變更需求的秘密武器未來在後面的文章中會介紹物件導向的招式與口訣，而這三個就是物件導向的心法現在不理解沒關係只知道有這三件事情就好

技術提供：Blogger