這篇文章是從我的 github 博客 http://lxconan.github.io 導入的。
今天這篇文章是準備瞎扯的。平常工作的時候，我希望盡可能的將一切自動化，讓自己盡可能的舒適與懶惰。兩個輸入設備（鍵盤+鼠標）太累，我只想用一個，例如我不希望翻箱倒柜的去翻找 GO-Agent 在哪里，我希望用一個命令就可以開啟它。我希望用一個腳本就完成整個工程的依賴的下載，構建，打包，部署，然后讓 Pipeline 去跑自動化的單元測試和集成測試。總之，好像有命令行就足夠了，我不需要GUI。
但是，這是不可能的。即使在工作中 80% 的時間都在敲打鍵盤，但是其余的事件我都在瀏覽器上轉悠，這需要鼠標（我知道 Chrome 上有類似 Vim 快捷鍵的東西，但是它是有副作用的，基于這種考慮，我很少在測試環境下使用它）。在其他的一些場景下，我也希望有接口有圖形化的表示，例如，查看 git 的分支。還有一個領域，那就是 Coach。
只有命令行的 Workshop 簡直弱爆了
相比于 Session 來說，大家更喜歡動手。這可能是由于 Session 以 PPT 為主，例子較少。在不能夠主動參與的情況下大家都昏昏欲睡。于是有了各種形式的 Workshop。但是我的確參加過類似于以下這種形式的 Workshop，完全沒有可視化的內容，只有命令行的操作，我很不喜歡，我只能說，它弱爆了。
例如，我們現在有一個配置 kvm 的 Workshop。主持人開場之后告訴你，很多版本的 Linux 已經自帶了 kvm。我給你的也是這個樣子的，不但如此，我已經幫你進行了一些基礎的配置。這樣我們就可以略掉很多繁瑣的操作。首先我們創建一個虛擬硬盤：
qemu-img create -f qcow2 winxp.img 10G然后創建虛擬機：
sudo qemu-system-x86_64 -m 512 -drive file=/home/lm/kvm/winxp.img,cache=writeback -localtime -net nic,vlan=0,macaddr=52-54-00-12-34-01 -net tap,vlan=0,ifname=tap0,script=no -boot d -cdrom /home/lm/iso/winxp.iso -smp 2 -soundhw es1370其中，-m 512 是分配 512MB 內存，-drive file=/home/lm/kvm/winxp.img,cache=writeback 是……
然后……好了我已經不想再說下去了。首先我很奇怪這種 Workshop 針對的對象是什么人呢？高手？那么他完全不需要來聽這些東西。初學者？拜托，你希望他照貓畫虎以達到培養量產型人才的目的嗎？這種可怕的 Workshop 的結果可能是：你準備好了一切，然后大家覺得一共就幾個命令，沒有學到什么東西；或者在 Workshop 進行的過程中問題層出不窮，但是當出現問題的時候你的聽眾根本不知道如何解決問題，只能干等著你來救命，或者干脆放棄這次的 Workshop。
你說，想成為高手必須自己如何如何……老實說，我認為你在赤裸裸的逃避身為一個 Coach 的責任。為什么大家只要一步跟不上就步步跟不上，或者即使是跟不上下來之后只能自己去重新整理。因為你沒有告訴他思路。你說不是啊，我告訴了啊，我每次都提前說，第一，……；第二，……；我只能說那是沒有用的。你最好用一個圖來可視化你的思路，或者此次 Workshop 的流程。例如：
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ Hard disk │ + │ Hardware │ + │ Host │ = Virtual Machine
└────────────────┘ └────────────────┘ └────────────────┘
↑ Install ↑ Config ↑ Download
| system | CPU, Mem | and
| on | Network.. | Install
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ Install Media │ │ configuration │ │ kvm │
└────────────────┘ └────────────────┘ └────────────────┘這個圖并不一定絕對嚴謹，但是他有三個好處：第一，極大的減輕聽眾的心理壓力，因為他們看到了這張圖會感覺到這個事情可能并不是那么難做；第二，防止聽眾 Lost，即便是他沒有跟上如何配置 Hardware 這一節，但是看了圖就知道這并不影響學習其余兩個部分；因此他就不會在下載并安裝 kvm 這一節還在不斷的琢磨，我剛才怎么就配不成 Hardware 呢？繼而加劇 Lost。第三，在某些部分 Lost 的情況下有據可查，方便線下自行練習。
另外，使用這種流程圖形還有一個好處，那就是聽眾會記住這些流程，進而會把自己的腳本按流程進行隔離，這總比把一坨東西都揉在一起好多了。
圖形是理解抽象的必殺技
有些時候我們不得不面對一些不容易描述的技術且難以調試的技術，例如 C# 的 Task Parallel System 。當你面對著如下的代碼的時候：
[Fact]
public async Task complex_await()
{
var numbers = new int[2];
string result = await Task.Factory.StartNew(
() => V.Start("task 1").Sleep(1).Finish("The numbers are: "));
for (int i = 0; i < 2; ++i)
{
int number = await Task.Factory.StartNew(
state =>
{
int stateIndex = (int) state;
return V.Start("task " + (stateIndex + 2)).Sleep(2).Finish(stateIndex*4);
},
i);
numbers[i] = number;
}
// ...
}有兩個急切需要解決的問題：
- 如何描述，大家才能夠了解這段代碼到底是如何執行的；
- 如果聽眾想自己做實驗，寫一段類似的代碼，那么他有辦法知道這段代碼是如何執行的嗎；
這兩個問題解決好了，那么你的 Workshop 不僅僅有魚，而且有漁。所有的參與者會非常好奇，他們不會滿足于只看懂你提供的例子，他們希望自己寫一些代碼，然后解釋他們的代碼是怎么執行的。為了達到這個目的，我寫了一個小小的工具，使得當你執行上述單元測試的時候，提供如下的輸出：
一切都是一目了然的，循環外的 Task —— Task 1 首先在 Id 為 7 的線程上執行，在執行完畢之后，循環中的兩個 Task 先后在 Id 為 8 和 Id 為 7 的線程上執行。三個 Task 有明確的執行先后關系，估計不用我說你也大概明白 await 的作用是什么了。如果你好奇心足夠強，就會自己寫一些更酷的代碼做測試，例如：
[Fact]
public async Task complex_await()
{
var ids = new[] {1, 2, 3, 4};
await Task.Factory.StartNew(() => V.Start("task 0").Sleep(1).Finish());
await Task.WhenAll(ids.Select(
id => Task.Factory.StartNew(() => V.Start("task " + id).Sleep(2).Finish())));
await Task.Factory.StartNew(() => V.Start("task 5").Sleep(1).Finish());
}那么你將得到如下的可視化執行效果：
你甚至可以用它探索 Task Parallel Library 中封裝的算法：
[Fact]
public void dig_into_the_algorithm()
{
Parallel.For(0, 10, i => V.Start("task " + i).Sleep(i % 3 + 1).Finish());
}你將得到類似下面的執行過程：
用神奇的圖形抓住聽眾
說實話，上面的圖表的截圖無法表現出他的全部。這些圖表不但是有一定交互性的，例如，將鼠標移動到某一個任務上，將顯示這個任務的開始，結束，執行長度等信息；而且是可以標記的。怎么樣，有趣嗎？如果你也想試一試，請參考我的 Workshop。如果你想看答案，請參考 lx_dev 這個分支。
我相信，只要我的自動化圖表足夠炫，你會有這種去下載代碼的沖動。這是聽眾的主動行為，代表了他們的興趣，有興趣還有什么搞不定的呢。
現實中復雜的東西實在太多，所以能夠理解這些問題的，我們會認為他們很厲害。但是這種厲害分為兩種，第一種是他講的我都聽不懂，有種不明覺厲的感覺；第二種是，這么復雜的東西能夠用簡單的例子描述出來，真厲害。我喜歡第二種。那么在制作 Workshop 之前，我們是不是應當好好考慮一下如何讓聽眾覺得即形象，又具備足夠的吸引力呢？
文章列表
留言列表
