跳到主要內容

千年一遇

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

搜尋此網誌

其他資訊

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

目前顯示的是 2025的文章

發表文章

桌遊矩陣潛襲資料收集與心得

張貼者：藍月日期： 11月 23, 2025

桌遊新世界

+

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

都2025了，技術主管的你還找不到想要的軟體人才嗎？

張貼者：藍月日期： 7月 18, 2025

+

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

其他連結

FB技術策展粉絲團

封存

2025 2
- 11月 1
  - 桌遊矩陣潛襲資料收集與心得
- 7月 1
  - 都2025了，技術主管的你還找不到想要的軟體人才嗎？

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

顯示更多顯示較少

標籤

軟體測試28
讀書心得25
Android23
Dart18
test18
人生14
程式觀念14
職涯14
給那個人12
Android筆記11

顯示更多顯示較少

檢舉濫用情形

RSS訂閱

發表文章

發表文章

所有留言

所有留言

熱門文章

BDD JBehave教學(1)使用心得

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

Cluster和HA的差別

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

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

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

(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

Android Keystore 實作筆記

先講一下使用情境， OWASP 說App內部儲存的資料有資安風險，要求加密，所以如果你手上有一些企業級的App，有一些很好心的單位，就會主動幫你做資安檢測，然後檢測項目就是根據OWASP去延伸。但我一直不能理解的是，Android本身的App資料預設就是只有該App能存取，就連使用者本身都要root才能去取得資料，而root這件事本身就是自己敞開大門歡迎小偷來偷，總不能說你買了一本筆記本，然後把提款帳號密碼寫在上面，放在客廳桌上，然後家裡大門不關，跟做筆記本的廠商說，你看你這樣會害我帳號密碼被偷有資安風險吧？之前也有機會問到某組織的資安組長，他說他們是在模擬器的環境中做檢測的，模擬器不等於真實環境，而且模擬器為了方便debug預設就是root，怎麼能依照這樣的流程來判定這樣有風險呢？再者我認為真正威脅應該是，在真實世界中我手機掉了，或者是我正常使用的過程中會導致帳號密碼被竊取或外洩，這才是真正有殺傷力的，不是嗎？回歸正題，所以在客戶端的資料如：SharedPreferences、SQLite，要如何加密呢？有三個方式客戶端加密建議使用AES加密演算法，但這種方式把是把key放在App裡面，只要反組譯App很輕鬆就可以取得key，比較進階的做法是使用NDK的方式透過C或C++的方式取得key，但這也只是增加破解難度而已，治標不治本 Server端取得鑰匙就是把key放在Server端，要用的時候再拿，算是安全但比較費工的方式使用 Keystore 前面講了這麼多知識廢話，現在要進入今天的正題了，Keystore是什麼呢？簡單來說他是系統提供一個存放鑰匙的地方，只有App能取得自己放的鑰匙，別人是不能亂拿的。所以在這個前提之下，我們就有一個可以在客戶端安全存放鑰匙的地方了，不過需要注意的地方是在Android 4.3(API 18)才有提供這個功能，而部分的演算法甚至要求更高的版本，所以使用前要先注意一下，像我這邊想使用的AES就必須要API 23才能使用。而在API 18我們能用的只有RSA，如果你只是要加密很短的資料，RSA就夠用了，但如果像我的需求要加密的資料很多，那會建議使用我等一下要講的進階用法。就是在Keystore的部份我們使用RSA演算法，但我們也使用AES來加快速度，做法是客戶端資料的加...

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

Dart的async/await理解筆記

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

抱歉，我搞砸了你的公司

心得管理一直有個很有趣的反思就是「我們真的需要管理嗎?」，不知道大家有沒有聽過螞蟻的故事呢? 他的大意是說螞蟻都很認真工作，但有一天老闆覺得管理很棒，好像大家都在講管理，如果導入管理，這樣螞蟻的效率一定能更加的提升。老闆花了一大堆錢來導入管理，但最後螞蟻們的工作效率不但沒提升，反倒被一些管理流程搞的效率下降。而本書也是有類似的觀點，這本書我最認同的一句話就是「所有管理的方法都只是一種掩飾，真正的目的是要讓大家坐下來好好溝通交流」。筆記每年都有新的模式或理論來解決企業問題但每個最新流行的方案都有其問題而這些問題又成為下一個方案的解決基礎錯誤的ＫＰＩ可能跟公司目標背道而馳流程才是出錯誤的地方，不是人讓所有人聚在一個空間討論他們為什麼這麼做、做了什麼、是否會影響其他部門的人、以及了解其他人的問題是非常有幫助的。顧問經理並沒有巡視廠房，也沒有和員工對話，但卻已經有解決的方法，只因為他在其他工廠很成功。最棒的是我們所有的管理方法都只是讓人們一起把事情做好的藉口。現在，卻變成人們一起把事情做好的替代品。要成功，就得把每個人含括在內。團隊問題不信任多頭馬車沒耐心怕看起來很蠢要小心的是把工具當解決方法，以為不用把人聚在一起就可以有效率的解決問題唯一改善營運的方法便是讓所有人一起參與。於是，用什麼工具或方法都無所謂，問題是人，解答也是人。我們鼓勵員工達到績效，但除了績效什麼都沒有不能有問題也沒有特例，就變成不用思考給方向而不是下指令『指標是工具而不是結果』數據指標是一場災難，因為他們取代了公司真正的目標。評鑑應該是幫助營運，而不是變成營運的一種方式。把評鑑放入懲戒制度裡，就表示指標變成了結果。管理評鑑的是人！有時候這可以操控評鑑結果！指標計分卡就像是車子的儀表板，但如果只看儀表板而不看路，一定會出車禍！讓員工自己訂下目標主管和員工一起，就能找出更好的辦法來達到公司的目標谷歌高效主管的八個習慣當個好教練授權團隊，避免事必躬親對團的成員的成就和心情，保持高度興趣注重生產力，用結果證明一切用心溝通，聆聽團隊聲音幫助你的團隊成員做生涯計畫團隊必須知道你有一個非常清楚的願景和策略擁有關鍵技術，以協...

Angular Dart 筆記(3) 架構

本篇參考官方文件 Architecture Overview 而來，這邊的程式片段都是來自教學，如果看不懂建議搭配著專案看。 Modules 核心價值模組化(Module)，也是程式設計概念推薦的做法，每個小模組做好自己的事情，然後可以將一堆小模組組合起來成為更大的功能。 Angular App是模組化，App是由很多模組組成的。

向阿德勒學習部屬育成心理學

從阿德勒心理學打破一般常識的論點，延伸到管理上面，依舊是突破平常認知的管理觀念，以不稱讚、不斥責、不教導三大重點為核心，而這三點正是管理上的常態，做得好要稱讚，做不好要責罵，正是管理中很重要的棍子跟蘿蔔哲學，卻被說成是不好的行為?更重要的是不教導，如果還不教導那....主管還要做甚麼呢? 但從書中心理學的角度來說還真的有道理，不用稱讚的方式而使用鼓勵的方式，將鼓勵重點放在對方的努力上，在心理學的研究上就是稱讚一個人很聰明(定型思維)，反而會使對方害怕犯錯，他會覺得是不是犯了錯就表示自己不聰明，而如果是鼓勵對方很努力(成長思維)，失敗了，對方也只會想成一定是哪裡沒做好，下次再努力就好。而成長就是要不斷地犯錯才會成長，不敢前進也就失去了成長的機會。責備的方式也會剝奪對方的勇氣，例如部下因為報告壞消息就被大聲斥責，未來部下就會愈來愈害怕報告壞消息，也會因會害怕責罵而不敢勇於挑戰與前進。而教導配合上棍子跟蘿蔔就變成了控制!而經由這樣控制三部曲訓練出來的員工，如果是很有想法很有衝勁的員工就會反抗最後離開。如果是原本就沒想法的員工，就會變成木偶，任由主管擺佈，說一動做一動，如果主管不下達命令，可能完全不知道該做甚麼，這樣是訓練員工?還是折磨員工?還是癱瘓員工? 最理想的狀態是讓主管像教練一樣的教練式管理，像運動員為自己的成績負責一樣，讓員工為自己的能力負責，而主管要以中立的角度提供客觀的數字，讓員工知道自己的能力到哪裡，如果不足可以請教同事或主管，這樣的關係會讓員工主動去思考自己的行為，決定自己的方向，而主管也會從舊思維的鞭策者變成新思維的協助者也就是教練的腳色，在心理學的角度來說，當人有能力決定自己的選擇與方向的時候，工作會更加投入也更有使命感，而主管變成協助者不但可以讓團隊關係更融洽，而主管的建議也會在員工向主管請教時才稍微分享自己的經驗，至於要不要使用就讓員工自己去決定，這樣的建議，效果絕對比命令還要來得好，就像北風與太陽的故事一樣。筆記試圖操控就失去信賴因為只看結果所以無法鼓勵他人 "稱讚"與"鼓勵"的不同下屬的報告做的很好 "稱讚" 你很能幹嘛。做得很好 "鼓勵" 非常好讀易懂。可以感覺到你仔細考慮過讀者的立場，下了一番功夫 ...

技術提供：Blogger