Metabase School, 遠端工作還是可以繼續跟大神們學寫 SQL


-

這篇文章記錄一個 side project - Metabase School 的發想、實作到上線的過程。

好 SQL,不學嗎?

一年多前,公司的 SQL 大神們開了一系列入門階級的內部課程,讓有興趣一窺資料相關領域的人可以一起學習。記得當時可是有來自各方的隊友們大力捧場,各種學、各種 query,有設計師、行銷人、product manager、HR、customer support 等等,幾乎每個團隊都有人來參一咖。而我,抱持著讓自己寫 SQL 的能力可以從 <= 0 提升到 > 0、拉近自己跟 product manager 的實力差距(沒錯,連 PM 都比我還會寫 SQL 🥲)這樣的心態,消息一出就手刀報名。

課程在 2020 年一月初展開,形式上有點像是「需要工人智慧監控的學校電腦課」,大家坐在同一間會議室裡,人手一機看著教學文件聽講,接著各自到我們常用的 query 工具 Redash 上實戰,這樣反覆地磨刀刷怪,每次大約一個半到兩小時。練習過程中如果卡關了,肩膀上來自大神的壓迫感就會越來越重大神們就會帥氣登場,親自手把手教學,傳道、授業、解 query error 也。

為了將焦點放回課程體驗本身,接下來的篇幅裡會以授課者取代大神們

然後就停課了

度過了兩、三回快樂的學習時光,課程因為新冠肺炎大爆發、公司轉為 fully remote 而被迫暫緩。主要原因是:課程中練習寫 SQL 的階段,在遠端的情境之下,授課者無法像在同一間會議室裡能隨傳隨到,難以維持以往的學習節奏

當時曾透過 Zoom 上過一次課,練習階段就需要透過輪流 screen share 或分享 Redash query 連結的方式讓其他人幫看,原本即時的幫助不再能即時,授課者也比較難掌控每個人的學習狀況。就這樣,開始了無限期停課。Slack channel 的名稱直接從 #sql-master-class 改成 #no-sql-master-class(並沒有這段)。

這是 Metabase School 這個 project 的開始。

幾週後的某天,我再度想起 SQL 課程,覺得應該要積極一波、嘗試運用技術的力量突破困境。不像大學時期,常以照顧室友的健康為由而在自己買宵夜時不聞不問不提供幫買服務。這回純粹想為隊友們在職場學涯的體驗盡一點心力,絕對不是因為自己手癢想寫一發、或是輪到我做 Dev Sharing 但不知道要分享什麼才決定挽起袖子試圖改變現況。

定義、拆解

讓我們先回到問題本身,當時我是這樣定義的:

因為授課者沒辦法即時幫大家看 query,所以

  1. 不容易即時得知大家的學習狀況

  2. 不容易提供即時協助

接下來,我開始想像要打造出來的東西需要具備哪些功用才能解決上述的問題。最終歸納出:要能讓授課者或其他同學們可以即時地互相看 query 和 query 結果

進一步拆解並列下可能的實作方向:

  1. 能夠即時地分享 query

    可以做類似 real-time collaborative code editor 來達成,例如:CodeSandbox Live、VSCode 的 Live Share Extension、或是公司其中一個產品 Codementor 的 real-time session room 不過是多人共編版本(目前僅一對一)。

  2. 能夠執行/下 query 並看到結果

    會需要串接公司既有的 query tools API - Redash 或另一個早期使用的工具 Metabase

一一擊破

帶著打造 MVP 的精神-先把關鍵的單點打通,先確認前面拆解出的兩個重要功能的可行性,確定單點本身能如想像中的運作後,再實作剩下的部分,把點跟點用流程和合理的使用體驗串起來。

以這次的情境我選擇先從第二部分「執行/下 query 並看到結果」下手,原因是因為「即時地分享 query」這部分我相對比較有把握。假設 query tools API 串接不如預期,那麼就算即時協作功能有做出來也是徒然。

執行/下 query 並看到結果

首先,我先瀏覽過 Redash 跟 Metabase 的 API 文件,最終發現 Metabase API 比較適合,需要被滿足的條件都有達到。以下是有使用到的 API 們:

天真如我,每個 API 用 Postman 戳戳看發現都能通之後就以為大功告成了,扣寫下去才發現完全忘了 CORS policy 的存在。因為牽扯到 hosting platform 的選擇,我後來選用了 Netlify 搭配 Netlify Functions 來繞過 CORS policy。API 介面完成!

即時地分享 query

之所以說這部分相對比較有把握,主要是因為「即時分享 query」功能本身跟 Codementor 一對一 session room 裡的 code editor 非常類似。它是基於 Firebase 的 collaborative text editor - FirepadMonaco Editor 的綜合體,用起來有點像 real-time 協作版的 VSCode。在打造 Metabase School 的時候如法炮製搞定這部分。

合理的 user flow 和介面

來到 user flow 的設計,大致的雛形是在確定 Metabase API 串接後跟著明朗起來。如同大部分的軟體服務,有些資源是需要有特定存取權限才有辦法取得的。在 Metabase School 的情境中,除了登入用的 API 之外,其他有用到的 API 都依賴著登入後取得的 session id。因此流程上會需要先讓 user 登入 Metabase 才能做剩下其他事情,真實的流程是這樣:

  1. user 來到 Metabase School 並登入

  2. (登入後) 來到有 code editor 的 query 頁面

    • 選擇資料庫
    • 寫、執行自己或他人的 query,以及看 query 結果

附上一些截圖

Screenshot of the login page of Metabase School
Login 頁面
Screenshot of the login page of Metabase School
Query 頁面

這邊說明一下 query page 的功能

任何參與者(包含授課者)都能即時看到其他人寫的 query,又因為大家用的 Metabase API host 是一樣的,就可以從自己的瀏覽器端執行別人的 query 並看到結果

同學上課囉

經過幾輪隊友們的測試後,SQL 課程終於以遠端的形式重新開張。非常幸運地,過程中主要功能沒有出什麼大問題,另外也收到了很多大家的回饋跟建議。順利完成 Metabase School 首航當下感覺蠻不錯的,用著親手打造的工具,讓自己和其他人可以持續享受這種主動付出相對較少的學習過程,有大神領門真的讚。

一點回顧與反思

一年過去了,SQL 課程也早已告一段落。最近一邊整理當時雜亂無章、各種 workaround 的亂扣,一邊回顧著整個發想、開發和實測的過程,在這邊記錄一下。

實作之前,問更多問題讓目標和方向更明確

有些時候遇到問題的人比表面上觀察到的問題本身還更重要,遇到痛點的是這些人,他們最能夠讓你理解真正應該解決的問題是什麼。這次的情境裡,因為我自己就算是其中之一,而問題本身也比較不複雜,最終的成品是有達到預期的效果的。但不同的情境牽扯到不同的人、痛點、困難等等,如果沒有針對可觀測到的問題往下探究,做出錯誤的假設和決定的機會是高的,遑論實作出的東西能否解決問題了。

還未被打造出的互動和連結

遠端當道,如何用科技或其他方式彌補在不同空間之下產生的不方便之處,變得相當重要,而我認為一定還有許多不同的互動方式等著我們去創造。Metabase School 告一段落後,剛好有機會開啟了跟打造互動有關的另一個專案

該做的 side project 還是要做

發現問題的人,可能就是最有能力且最應該解決它的人。

任何追求成長的群體中,一定會有流程、合作方式、思路等等可以優化的地方,如果遇到這種機會就嘗試去解決他吧!