VIVOTEK Digest

經濟部統計處: 飲料店營業額在台灣逐年攀升

第一個常見現象：開週會
Why are meetings so ineffective?

Great movies tell stories that have deep emotional resonance

第二個常見現象：同事間的工作互換困難
Why is collective work difficult?

Machine learning or human learning?

第三個常見現象: 加班

Why work overtime?

不同角度的生命科學系

又下班了?! 我還想工作

Schrödinger’s Cat 薛丁格的貓

敏捷開發
Why OverCooked can teach you agile?

一款具備敏捷精神的遊戲

Get back in sync

Realtime review

The programmer as navigator

How to avoid boring meetings?

How to develop a cohesive team?

合作或協作（英語：Collaboration）

是指一種由兩個或兩個以上的個人或團體作為一個共同的目標而交集或在一起共同工作，舉例說明：

一個知識分子可以透過合作的關係而去分享知識，再而經過學習和共識達到創作的目標

一個人走得快

一群人走得遠

 Why collective intelligence matters?

Pacific Rim: Uprising (2018)

True collaboration yields better results

Iteration based method

Jeff Patton did an Iterative Mona Lisa.

敏捷帶來的影響
How does agile affect my work and daily life?

從同事電腦辦公桌

變家人散步吹吹風

關門 SOP

前是把家當旅館

現在是家事盡量管

從擔任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 meeting時的依據，
檢視列為action plan的項目是否有被執行，讓自己變為一個秘書或監督者的角色。

接著是第二階段，我參加了呂毅老師CSM的課程。
在兩天的課程中我學到最多的不是ScrumMaster該做什麼，而是ScrumMaster「不該做」什麼。
課程結束後我期許自己往教練的角色前進，以引導來取代教導；
列出了ScrumMaster該有的特質貼在螢幕前常常提醒自己，尤其是要有耐心，
不要認為自己比集體智慧還要聰明，給團隊足夠的時間，讓他們自己找到答案。
我開始站在團隊成員背後，不再參加planning meeting part.2，
daily時看到問題不會急著指正，只是記下來作為retrospective meeting的準備。
不再由我負責retrospective meeting的紀錄，由團隊自行決定到底要不要寫，
兩個團隊討論後各有各的作法，但都決定不再像之前一樣記在OneNote上。
團隊在這階段有更多的自主性，更符合自組織團隊的定義；
作為交換我們付出了一些代價，例如sprint失敗的機率增加，
在產品開發有些欠缺考慮的地方，造成品質下降。

來到今年，由於新人陸續的加入(佔了1/3)，兩個團隊重新分組。
Scrum的核心在於隨時檢驗與調適，依據上階段的成果和團隊目前的情況，
我又調整了自己的工作模式。
扮演理想ScrumMaster的前提在於你有理想的團隊成員，Scrum對此沒有明確定義；
就我的認識，我會以《Google模式》裡的智慧創做者(smart creatives)作為標準，
具有深厚的技術或專業能力，還有創造力與實踐執行的能力，
而且充滿好奇、質疑現狀，以不一樣的方法來應付問題與挑戰。
新人比例偏高加上重新分組，讓團隊的發展回到第一階段的成形期，
除了教練的身份外，我更需要的是老師的角色，傳承我的能力和經驗。
我又開始全程參與planning meeting part.2，只是我不再主導而是提醒，
在團隊的討論中丟出問題，提醒他們沒考慮的地方。
重點不在於討論出什麼樣的解決方案，而在於提問以引發討論，
藉由一個一個問題去淬鍊出越來越好的作法；
必要時我會補充技術上的專業，只有我具備而其他人不知道的資訊來協助討論。
在daily meeting和retrospective meeting時，我依循相同的精神和團隊互動，
依據要處理的課題切換我頭上戴的帽子，可能是ScrumMaster或是資深工程師。

Scrum沒有標準作法，在不同的環境(context)中會有不同的應變，
一切都是trade off，只要想清楚每一個決定的得失，是否合乎敏捷的精神？
最忌諱憑直覺作出反應，讓自己習慣於過往的工作模式。

1. 每個 column 個都要多一個 column 來儲存 uncompress 的 string (除了不用搜尋的 snapshot & timestamp column), 但這會增加整個 database 的 size
2. or 要增加 compress, uncompress function 在 Create Table 時加入 https://www.sqlite.org/fts3.html#the_compress_and_uncompress_options , 但這要直接使用 SQLite 的 API function, 對我們使用 Qt 包一層的 API 不好實作

針對常用的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住. 針對這部分的參考解法大致如下,

1. maintain一個QHash把每個model item的IdRole value跟相對應的model index存起來
2. 複寫match, 如果是是要查IdRole, 就直接從QHash找以提升效率
3. 由於QStandardItemModel::clear本身不會觸發rowsAboutToBeRemoved, 所以即使呼叫clear, 還是要主動去清掉hash

#include <QHash>
#include <QModelIndex>
#include <QPersistentModelIndex>
#include <QStandardItemModel>
#include <QVariant>

class MyListModel : public QStandardItemModel
{
  Q_OBJECT

public:
  enum Roles
  {
    IdRole = Qt::UserRole + 1,
    DataRole
  };
  MyListModel(QObject *parent = nullptr)
  {
    // 把每個model item的IdRole value存到QHash裡, key是id, value就是model index (必須用QPersistentModelIndex)
    // 如果是tree model記得要recursive把childrn也加進來,
    // 主要是如果使用者是先把model item的children都append好, 再append本身進來的話, 只會觸發一次rowsInserted.
    QObject::connect(this, &QAbstractItemModel::rowsInserted, [=](const QModelIndex &parent, int start, int end) {
      for (int row = start; row <= end; row++)
      {
        auto mdIndex = index(row, 0, parent);
        auto id = data(mdIndex, MyListModel::IdRole);
        m_idModelIndexHash.insert(id, QPersistentModelIndex(mdIndex));
      }
    });
    QObject::connect(this, &QAbstractItemModel::rowsAboutToBeRemoved, this, [=](const QModelIndex &parent, int start, int end) {
      for (int row = start; row <= end; row++)
      {
        auto mdIndex = index(row, 0, parent);
        auto id = data(mdIndex, MyListModel::IdRole);
        m_idModelIndexHash.remove(id);
      }
    });
  }
  virtual ~MyListModel() = default;

  // 覆寫match function, 如果針對IdRole就去QHash以提升效率
  virtual QModelIndexList match(const QModelIndex &start, int role, const QVariant &value, int hits = 1, Qt::MatchFlags flags = Qt::MatchFlags(Qt::MatchStartsWith | Qt::MatchWrap)) const override
  {
    if (role != MyListModel::IdRole)
    {
      return QStandardItemModel::match(start, role, value, hits, flags);
    }

    // todo, !m_idModelIndexHash.contains just return empty can enhance performance, but m_idModelIndexHash must be 100% correct
    if (!m_idModelIndexHash.contains(value))
    {
      return QModelIndexList();
    }

    return QModelIndexList() << m_idModelIndexHash.value(value);
  }

  // 由於QStandardItemModel::clear本身不會觸發rowsAboutToBeRemoved, 所以clear記得要主動清掉hash
  void clearIdHash()
  {
    m_idModelIndexMap.clear();
  }

  QHash<int, QByteArray> roleNames() const override
  {
    QHash<int, QByteArray> hash;
    hash[MyListModel::DataRole] = "dataRole";
    hash[MyListModel::IdRole] = "idRole";
    return hash;
  }

protected:
  QHash<QVariant, QPersistentModelIndex> m_idModelIndexHash;
};

延續"flags對QAbstractItemModel::match的效能影響"中的實驗方法,
如果利用QHash得到的結果如下,

match from	elapsed (ms)
QStandardItemModel::match	55194
QHash	63

由此可見效率是大大大大提升的, 缺點就是你要好好管理m_idModelIndexHash, 一有差錯都會導致model行為不正確.

秘訣: 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中 flags 參數其實是蠻巨大的.
一般我們在輸入這個 flags 通常都是 copy / paste 舊有的 code , 所以最常看到的組合就是"Qt::MatchFixedString | Qt::MatchCaseSensitive | Qt::MatchRecursive"如以下所示,


model.match(model.index(0,0), IDRole, value, 1, Qt::MatchFixedString | Qt::MatchCaseSensitive | Qt::MatchRecursive);


這是很沒有效率的, 例如對100000筆資料的list model中針對int value作match得到以下的結果,

match for int value flags	elapsed (ms)
Qt::MatchFixedString | Qt::MatchCaseSensitive | Qt::MatchRecursive	125593
Qt::MatchFixedString | Qt::MatchCaseSensitive	120216
Qt::MatchExactly	22162

由此可見型別搞錯會造成的影響有多嚴重,
還有一點就是如果是list model的話, 就不必要下Qt::MatchRecursive, 這樣又可增進一點效能.
另外對string value作match得到的結果如下,

match for string value flags	elapsed (ms)
Qt::MatchFixedString | Qt::MatchCaseSensitive	56188
Qt::MatchExactly	55194

於此可見, 如果match要compare的value是要完全一致的, 其實只要使用Qt::MatchExactly就萬無一失了.