VIVOTEK Digest

         從 Clean Architecture 我們學到要把程式架構畫出來，把核心邏輯與其它細節分開來, 避免核心被汙染，達到最終目標：「最小化軟體生命周期的總成本+最大化程式設計師的生產力」。書本裡面給了一個四層的架構圖：Enterprise Business Rules, Application Business Rules, Interface Adapters, Frameworks & Drivers。簡單說前面兩個就是策略、業務規則、核心價值，後面兩個則是細節、資料庫、框架、通訊協定…等等。在這樣的分層規劃下，我們得以確認依賴關係是由外向內的。如果有需要，我們會利用依賴反轉(Dependency inversion principle，DIP)來維持核心的整潔，這樣的架構也允許我們延遲細節的決定。 事件風暴     第二堂課, Teddy帶我們體驗事件風暴(Event Storming)，事件風暴是一種快速讓群體進入狀況, 跨部門達成共識的方法，不限於軟體，其實可以應用在各種業務領域，協助建構模型。事件風暴的介紹網路上可以查到很多，規則與範例就不在此贅述，因為事件風暴最重要的是溝通的過程，使用文字敘述很難體會，課程後我與YK(同事)為了讓更多同事也能了解這個溝通方法，因此辦了一個小workshop，邀請了三個不同部門的同事，其中包含測試部門、韌體研發、新技術開發部門一起共同討論「韌體自動化測試工具」這個主題。 共通語言...

在我們團隊快要一年了 一年的時間 寶寶可以長牙 台灣可以賣出 10 億杯飲料 營業額可以突破千億… 經濟部統計處: 飲料店營業額在台灣逐年攀升 不說飲料 最近回顧了這一年的行事曆 我是有點吃驚的 OMG! 原來工作的方式，可以這樣影響生活 越工作越有活力 如何影響呢？ 我先賣個關子，先來看幾個大部分的組織會遇到的現象。 第一個常見現象：開週會Why are meetings so ineffective? 一個規模不大的四人團隊 一人報告一小時 一場 weekly meeting 就是四個小時...

我們再歸納一下，一般的組織常遇到三個現象: 1. 開冗長的週會 2. 同事間工作互換很困難 3. 加班 而我們 team 恰恰相反，有這三個很獨特的地方: 1. 不用開週會 2. 協作容易，你的同事就是你的分身 3. 不用加班 這些特徵好像很難同時並存，你想，不開會怎麼知道同事在做什麼? 同事之間不了解，溝通成本就大 人越多就越複雜，花的時間也多 怎可能不用加班事情還能準時做完? 敏捷開發Why OverCooked can teach you agile? 來講講 OverCooked...

從擔任ScrumMaster九個月以來，經歷了三個時期的轉變， 猶如禪宗《指月錄》裡，「見山是山，見山不是山，見山還是山」 的三重境界。 我是以R&D team leader的角色轉職ScrumMaster，是團隊成員的直屬主管，擁有人事的管理權(招募、解雇及績效考核等…)。 在Scrum的相關介紹裡，都會建議讓ScrumMaster單純化，不要擁有管理權， 這會讓團隊成員對他頭上戴的帽子是ScrumMaster或是主管感到困惑，甚至妨礙自組織團隊的形成。 往好處想，由於有主管的職權，在推動一些政策或改變時會比較容易， 前提是你必須確保自己要推行的事情是正確的。 既然這是無法避免的問題，我告訴自己要學會竭盡所能解決任何潛在的利益衝突， 尤其是要保持開放的心態鼓勵溝通，避免以威權領導團隊的情況發生。 即使有了心理準備，工程師畢竟是一種過於樂觀的生物， 執行時仍是遭遇了合併角色時可能會犯的那些錯誤。 首先遇到的是我們在doing agile而不是being agile， 我們遵照Scrum的規則執行必要的活動，但活動的進行卻不夠符合其背後的精神。 從Scrum第一天的planning meeting開始，我主導了如何將sprint backlog item拆成task的過程。 daily meeting時我站得太前面，像是傳統的那些會議，部分團隊成員習慣直接對我報告，而不是其他成員。 當進度落後時，我會主動提出「建議」改變工作的進行方式， 理智上知道sprint是可以失敗的，仍然將sprint是否成功作為我的職責，想方設法的讓團隊可以在時間內完成。 retrospective meeting時我會幫團隊寫下會議紀錄，作為下次retrospective...

DataMagnet 是讓客戶能夠透過 HTTP POST 傳送 JSON data 並儲存各種資訊到我們的錄影軟體 VAST2, 再透過 VAST2 來搜尋內容的功能  客戶用我們的 data magnet 功能, 一天下來會有好幾萬筆的資料，而且內容是夾帶著 image 的 data (base64 format) 而如果這樣的 data 有幾百萬 or 幾千萬筆的資料在 db...

針對常用的match role, 可利用QHash (or QMap) 多存一份, 來加快 search 效率 我們在設計model通常都會定義一個存unique string value的IdRole當作model item的索引, 且會很頻繁對這個role作match, 從"flags對QAbstractItemModel::match的效能影響"中的實驗中可知, 針對string value去作match在效率上是很糟的, 所以只要model數量大到一個程度, 就會很容易使UI thread hang住. 針對這部分的參考解法大致如下, maintain一個QHash把每個model item的IdRole value跟相對應的model index存起來 複寫match, 如果是是要查IdRole,...

秘訣: flags 只要用 Qt::MatchExactly 即可, 如果是 tree model 則再加上Qt::MatchRecursive QModelIndexList QAbstractItemModel::match(const QModelIndex &start, int role, const QVariant &value, int hits = 1, Qt::MatchFlags flags = Qt::MatchFlags(Qt::MatchStartsWith|Qt::MatchWrap)) const QAbstractItemModel::match中...