千年一遇

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

顯示更多顯示較少

flutter9
Java8
Switch8
桌遊新世界7
愛的極白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
跨平台3
AWS Device Farm2
Angular2
Firebase2
Gradle2
Ionic2
JBehave2
JMockit2
database2
weka2
壘球2
理財2
翻譯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
資料庫(Database)1
資料探勘1
資深軟體工程師的自我修練1
部落格規定1
青鳥的尾巴1
食記1

顯示更多顯示較少

RSS訂閱

發表文章

Atom

發表文章

所有留言

Atom

所有留言

Cluster和HA的差別

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

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

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

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

我們與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 或是探索出一些規格上當初沒定到的需求或邏輯，這部分是我覺得很難用工具取代的部分，而規格上有的邏輯就可以使用軟體測試去驗証減少人力在回...

程式碼中的魔術數字

原本以為很多文章都會提到，沒想到稍微google一下中文資訊居然這麼少，既然自己的文章提到了，那就自己說明一下吧。

Firebase 服務在 Android App 上使用的簡單心得記錄

好久沒寫技術文章了，趁著還有點時間，來記錄兼分享一下今年玩Firebase上一些服務的想法與心得。開發 Cloud Firestore 開發這塊其實沒甚麼好說的，要細講太瑣碎，要簡單提一下其實也大家都有了，沒什麼特別的地方，只好拿Cloud Firestore出來說，這個算是讓我覺得Firebase可以真的拿來做東西的開始，之前的Realtime Database真的是搞笑，主打realtime但真的有這樣需求的App其實非常少，最普遍的情境也就是聊天室，然後沒有這樣的需求他就是一個難用得要死的Database，雖然Cloud Firestore還是不支援地點的查詢，但支援集合跟一些勉強堪用的查詢，用來做一般情境下的App都算是夠用了，在這個前提之下用Firebase + Flutter來做試水溫的MVP根本完美組合。品質 Crashlytics 這個就是收集App Crash的服務，提供不錯的後台可以當簡單的問題管理系統，在還沒被Google收購時就有在用，算是App必用服務，不知道這個服務我會懷疑你沒寫過商用App。 Test Lab 這個其實是我蠻期待的服務，分成兩塊來說，Robo測試算是很讚的懶人包，App閉著眼睛丟上去，就可以幫你測很基本的各功能會不會Crash，官方的說法是像爬蟲機器人，去爬畫面上的View並操作，也有提供線下版，也能自己錄腳本，但缺點就是腳本錄製的過程介面操作跟反應都非常慢，而且沒提供官方文件說明讓人自己手寫腳本，所以我都只用在上版前Google Play的正式發布前測試報告這塊。而檢測設備測試，又再讓我感受到這個服務沒有做得很用心的點，如果選虛擬手機來測試在輸入時會跳出奇怪的權限要求，非預期的事件導致測試就會掛在這，這塊就很好奇是只有我會遇到，還是其他使用者根本就不用?當然選擇實體手機測試就不會遇到。 App Distribution 這個服務算是為了讓Fabric的Beta使用者能順利遷移而給的功能，但不支援App Bundle就是塊雞肋，所以這功能我沒用，而是使用Google Play中的『內部應用程式分享』來取代，但注意用這方法測試憑證會被換掉，要注意後續引發的問題。數據分析 Events 算是整個數據分析最重要的主軸，後續強大的服務，都需要靠Event...

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

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

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

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

桌遊反轉寓言開箱紀錄

同捆包裝的正面以前在網路上看到扭曲寓言的資訊時，其實有被他的設定跟美術深深吸引，印象中柔柔弱弱的童話公主們，一個個都形象大反轉的來格鬥，看起來就很吸引人再加上它的美術設計，本來我是比較喜歡日系風格，而這桌遊其實比較偏美系但我意外的能夠接受，甚至還蠻喜歡的，本來之前就有在考慮購買，但之前只有簡體中文跟英文兩種版本，那時候就懷抱著不切實際的期待，想說如果有繁體中文再來買好了，沒想到前一陣子居然真的在嘖嘖募資平台上出現了，也改名叫反轉寓言，二話不說就下訂了，想說當自己的生日禮物，沒想到後來順利的提早出貨，讓我可以在生日前收到這款桌遊。參與募資價格與內容物但還是想小吐槽一下，嘖嘖都快變成試水溫&行銷平台了，有些東西都已經有在販賣，還跑來群眾募資平台?猜想該不會是玩樂小子內部有人其實沒這麼看好這款桌遊，所以到嘖嘖試試水溫吧?但不得不說這類募資平台限時販賣加上募資金額如果達到部分標準就會解鎖一些限定商品，成功營造出稀缺性與遊戲性這部分有牢牢的抓住人性，也成功讓不少商品發光發熱，不過蠻可惜的這次反轉寓言的專案看起來沒有特別注重在這塊，解鎖限定商品也只有閃卡、塑膠指示物跟同捆包裝，但不得不說本身美術營造出來的質感+價格也是讓它賣出了不錯的數字，本來預期十萬成案，最後募到了一百多萬，但跟簡體中文版比較起來，簡中版本還有角色隔板跟可以完整收納模型、遺跡牌墊跟所有牌的大盒子(參考簡中開箱影片 )，繁體中文的盒子只能放下所有上了牌套的卡片跟2v2的塑膠板，遺跡牌墊放不下，當然這可能是不同的考量，比如攜帶去別人家玩時，可能就不一定要帶模型跟牌墊出門，那繁體中文的盒子就會相對俐落一點，另外一個重點是繁體無價（喂，順帶一提簡中版本的價格是2750（預購價）/3290。同捆真的是外面用一張紙像壽司一樣把其它盒子捆起來基本組的盒裝正面看到這包裝也是能理解廠...

技術提供：Blogger