近況報告 2019 June

Bruce Li

11 min readJun 30, 2019

自從上次近況報告後

四月去日本玩

今年又去了日本，除了在横浜的主行程 LiSA 演唱會之外，因為季節剛好，也想順便看個櫻花。不過四月底東京已經剩葉櫻了，所以得往北跑。既然要往北跑，就順便看看幾個名景點吧。這次行程基本上就是用這種感覺訂出來的。

主要行程我有寫成遊記

日本遊記 & lesson learned & 推薦 2019

我去日本爽了一圈。

medium.com

加入 WORD UP 創業中

之前提到我加入了一個創業團隊。這次差不多可以來分享一些細節了。
這個團隊是 WORD UP，以英文單字卡起家的服務，開始全職做以後，目前朝向參考書商城發展。個人認為這個題目可能不到光鮮亮麗，但需求是有的，而且會改善到很多考生的升學或升遷之路。

我們在 AppWorks 18 Demo Day 的發表：

我加入的機緣是這樣的，去年離開那家讓我因此愛上 LiSA 的公司以後、加入了 MoneySmart，裡面有個跟我不同 team 的台灣工程師，就是他勸誘我加入他當時還是 side project 的團隊。一開始是義務幫忙，直到今年初大部分成員轉正職、成立公司、找錢。

特地花版面講這些不為了別的，就是 — —

我們正在徵人

這邊先離題一下，這個小節是這次近況報告我覺得最難寫的部分，要斟酌很多東西，但後來想想，既然是我的近況更新，就不多說徵人用的場面話了，以下誠實說。

考慮到沒錢又缺人但進度一直都在火燒屁股的創業早期現實，我們目前想徵一位 junior iOS developer，由我們的雙棲 mobile developer 指導，好讓她之後可以花多一點時間在 android 版本上。

也來講一下我看重的點，我認為工作者考慮加入一家公司最重要的原則是：

別兜售你自己不會購買的東西。
別為你不尊敬、不欽佩的人工作。
只跟你喜歡的人共事。

（引用自《窮查理的普通常識》）

這幾年我一直用這個標準來為每份工作評分，WORD UP 是目前為止綜合評分最高的 — — that being said，對我高分不見得是對你高分。

首先我一直想加入 productivity tools 相關的 startup，我喜歡做一些工具來讓做某事的效率提高。這個主題是讓檢定學習的效率提高，有打中我的點。

老闆是前同事，所以工作習慣多少都有點了解了，老闆是屬於行動派的，但思考也很清晰。像我這種常常思考太多、出手太慢的內向型都不見得能常在討論中挑到毛病。

目前大部分成員都是 co-founders 的前或前前同事，工作習慣都很好，例如要用什麼技術會有熱烈的 debates，但該 move forward 的時候也很團結。這看起來很理所當然，但這幾年我遇到不少「意見很大聲但做不出個什麼成果」的人，甚至「講不聽、不願讓步」，「呼籲大家要配合他但反過來都不配合」的拖後腿者。就覺得這很難能可貴。

也許也是團隊還小，速度、彈性和融洽不太是這階段會有的問題，但也因為很早期，我們也一直有意識的塑造我們想要的文化。

雖然有點自賣自誇，但我自認我對軟體工程的實踐的平衡度算好的，塑造工程團隊文化也有經驗。

如果覺得這樣的主題、挑戰、環境有興趣，歡迎跟我聯絡，我的 Gmail, twitter, facebook 帳號都是 “ascendbruce”

最近我也進一步調整我的工作流程與工具

前些日子 Butler 被 Trello 買下來了，原本要另外付錢的 Butler 跟 Trello 的付費方案整併，現在只要買 Trello 付費版就可以用 Butler 了。於是花了點時間進行嘗試，組出了一些我想要的應用，有些是我一直希望 Trello 會內建的功能，現在終於可以透過 Butler 實現。這邊分享幾個比較泛用的給大家：

Trello 一鍵套用 Description 樣板

按一下就可以填入預先設定好的樣版。除此之外也會保留原先的內容，以防手殘誤按。

設定

要注意如果分享 Butler Buttons 給其他免費成員的話，對方只看得到一個按鈕，其他的會被隱藏。（Trello 免費方案的限制）

Trello 自動雙向連結

靈感是大部分 issue tracking system 加關聯票的時候都會自動加反向的連結，甚至連 GitHub 都會，但 Trello 居然沒有，必須手動按兩下。

Before (要手動按 “Connect cards…” 再按 “Relate Both Cards”)

After (自動連結)

設定

Trello “In list since” 資訊

加上「這張卡在這個 list/board 待了多久」的資訊

靈感來自 Time In List

可是 Time In List 要錢，用 Butler 又無法直接重現該功能，所以折衷就是壓個 timestamp 但不換算成經過的時間，然後順便加個 log。

這個可以有很多變化型，例如採用 scrum 的團隊可以考慮用成 added since 跟 started since (對應到 lead time 跟 cycle time）

設定

Gmail 自動封存兩天以上的 email

我發現對於雜事，我很適合「放棄思考」策略

例如我之前做過一個 Download Folder Cleaner，這個工具解決的問題是：Download 資料夾常常堆積到難以管理、但又不敢全刪除的狀況。

很容易想到的對策是「每天檢視有沒有可以刪掉的東西」，但與其要記得主動做某件事——很容易破功，不如弄成「留在這裏的東西晚點都會自動丟掉，所以有用的東西下載後馬上歸檔定位」。我採行這個策略已經一年半了（自從 2017 年 1 月），自此以來再也沒有因為堆積而困擾、也沒有發生過「因為自動刪除到有用的東西而困擾」的狀況，因為真的超過時間的話還是可以從垃圾桶找回來。我甚至把 Screenshot 的儲存位置改到 Download 資料夾，所以桌面也沒有任何檔案堆積。歡迎採用我的 script，有 open source 所以不用擔心我會偷你資料 XD

不過今天的重點不是 Download folder 的整理，而是最近靈光一閃想把同樣策略套用到 Gmail，搜尋一下發現也早有人做過了。

首先參考這篇把 Google App Script 設定起來

之後我稍微調整成符合我的需求，以下是完成的 Script，歡迎取用

// Originally From
//
// https://medium.com/@fw3d/auto-archive-emails-in-gmail-after-2-days-1ebf0e076b1c
// https://gist.github.com/anonymous/2cca33d376f7f924fdaa67891ad098cc
// https://developers.google.com/apps-script/reference/gmail/function gmailAutoarchive() {
  
  var delayDays = 2; // will only impact emails more than 48h old
  var maxDate = new Date();
  maxDate.setDate(maxDate.getDate()-delayDays); // what was the date at that time?// Get all the threads
  var threads = GmailApp.search('in:inbox older_than:2d -is:starred');
  
  var label = GmailApp.getUserLabelByName("AutoArchived");
  
  // we archive all the threads if they're unread AND older than the limit we set in delayDays
  for (var i = 0; i < threads.length; i++) {
    // hasStarredMessages is more reliable than "-in:starred" search
    if (threads[i].getLastMessageDate()<maxDate && !threads[i].hasStarredMessages())
    {
      label.addToThread(threads[i]);
      threads[i].moveToArchive();
    }
  }
}