第一次跳槽 vscode 就上手
故事是這樣子的，小弟第一次學寫 code 的時候，是在大一修計算機程式（嚴格來說是高三下學期上了幾個小時的 C，不過那實在稱不上是"學"）的時候，第一個使用編輯器是破舊破舊的 Dev C++ ，我打這篇的時候差點都忘了它叫 Dev C++ 了。
當然那時候的功力跟現在實在是天差地遠，淨寫一些垃圾，啊雖然現在也是淨寫一堆垃圾…。
總之後來應該是大二，被同學們拉去演算法課上當砲灰，第一次接觸了工作站 + vim，從那時候把 Dev C++ 給丟了跳槽到 vim，就一直用到現在，
之中當然也會用一下其他的編輯器，像是改 windows 的 .NET 程式用到 Visual Studio，但大體還是以 vim 為主力，算算也是超過 10 年的 vimer 了。
不過這兩三年在工作上、日常 project 上面，多多少少都見識到 vim 的不足之處，例如
- 新語言（主要是 rust）支援不足
- 跟編譯除錯工具整合不佳
- 跟 GUI 整合不佳
- 跟 Git 整合不佳要另外開終端機跟 gitg
- 自動格式化/排版操作麻煩而且通常排不好
正好此時 Microsoft 回心轉意擁抱開源，推出了 vscode，隔壁棚的 emacs 有大神跳槽鬧得風風雨雨，
台灣 CUDA 第一把交椅強者我同學 JJL 也跳槽 vscode 惹還來傳教。
使用 git submodule 管理 project 所需的其他模組
故事是這樣子的，最近在寫一些分析資料的程式，用的是 python 跟 numpy。
一開始改寫的時候，發現一開始 load 資料的地方，Python 實在太慢了，載入 20000 筆資料耗時超過 150 秒，後來決定用 C++ 改寫載入數據的部分，同時利用別人寫好的 cnpy 這個 project，寫出 numpy 檔案作分析，結果載入速度竟然一口氣降到 4.5s，加速 15 dB，太可怕了(yay。
為了要使用 cnpy 這個 project，順手研究了一下要如何給使用 git submodule，這篇文章就做個介紹。
Git 教學影片系列
故事是這樣子的，自己大概三四年前開始使用git，一路用到現在，對 git 相關的功能算是相當熟悉，有時也會負責教其他人使用 git，自己的 blog 上其實也留了不少 git 相關的文章：
大約兩個禮拜前突發奇想，反正都要教，乾脆就錄個影片，以後只要貼影片給別人看，不只教認識的，還能教虛擬世界中「沉默的多數」（誤），想著想著稍微規劃了一下，好像還真的有點模樣，於是就開始了我變身網（ㄈㄟˊ）紅（ㄓㄞˊ）的第一步。
使用 git-svn 和 svn 遠端協同開發
最近因為跟人協作，共同開了一個版本控制資料夾。
對方使用的版本控制是 svn ，而我則是用 git，重新學 svn 實在太麻煩了，有沒有一個好的解決方案呢？經過強者我同學 AZ 大神跟 qcl 大神的推薦，決定使用 git-svn 來解決。
使用 git patch 來搬移工作內容
前幾天在改一個專案，因為筆電的設備不夠強大，只能到桌電上開發，兩邊都是開發機，也就沒有用remote 的方式來同步專案。今天，要把那時候的commit 搬回筆電，只好使用git 的patch 移動工作內容，這裡記錄一下整體工作流程和解決衝突的方法。
如何在Pull request 被mergerevert 後再送 pull request
自從換了智慧型手機，又搭配1.5G的網路之後，用手機上網的機會大增，在用Firefox 刷Facebook 的時候，很容易跑出廣告來，於是發想把「在Yahoo 台灣大殺四方驚動萬教的人生溫拿勝利組強者我同學 qcl 大神」所寫的神專案QClean 移植到Firefox Mobile 上面。
使用git hook在commit 前進行unittest
使用 git 做為版本控制系統已經有一段時間了，最近在寫Facebook message viewer 的時候，就想到能不能在本地端建一個 CI，每次 git commit 的時候都會時自動執行寫好的測試？
查了一下就查到這一個網頁 裡面有相關的教學：
在這裡記錄一下相關的設定。
使用git rebase 進行Pull Request 檢測
故事是這樣子的，自從我被加到Qucs project的專案小組，原本的管理員又因為博班進到最忙的時間開始比較少管事，變成我在管專案的Pull Request(PR，拉取要求)。
其實管就管，反正這個project 沒人鳥，平常也沒什麼PR進來；不過有PR進來的時候，還是要做適當的檢查，以下提一下幾個檢查PR的流程：
使用git bisect 搜尋災難發生點
之前因為強者我同學阿蹦大神的關係，接觸了neovim這個大型專案，光星星數就有9300多顆，是我星星最多的project的9300多倍lol。
雖然說看了幾個issue，大部分都插不上話－－討論的層次太高了，偶爾有個好像比較看得懂的，trace下去之後提出解法，沒想到是個不徹底的解法，pull request就被拒絕了TAT，要參加這個超過9000顆星星的project，像我這種花盆果然還是「垃圾請再加油」
雖然說是這樣，但我還是趁這個機會，研究一下如何使用 git bisect 在project裡面找到洞洞。
基本上project無論用了多少test，多少還是跟我的腦袋一樣有一些洞，要如何找到洞洞就是一門學問了，git 提供了git bisect這個指令幫助開發者找到出錯的地方
Git-flow 簡介
最近因為工作的關係接觸了git-flow相關的內容，在這裡就介紹一下git-flow的相關概念。基本上git-flow就是一個git 的擴展，把一群git 指令集合在一起，更方便管理人的操控，如果去看它的執行檔，其實就是一個shell script，所以使用git-flow時也可以用git 指令，同時只要熟練git的話，就算不用git-flow 也能操作自如。
我認為git-flow最重要的還是背後那個分枝的規則，我覺得學起這個規則就好。