[Memo] 數位游牧的生活 Part End

Image Credit

13lkg0agi0.jpg

時間過的真快，這兩年的游牧生活在最近算是告了一個段落。兩年的時間說長不長說短不短，中間也發生了各式各樣的事情，所以想把這兩年做一個總結記錄下來。

喜好、堅持、技術偏執

我覺得有時候技術人通常都會有這個問題，不論哪方面的技術、哪個領域的專家，通常都有自己擅長的工具，輕微可以稱為喜好，嚴重點可以稱為堅持或是技術偏執。如果今天是個一人團隊，你想要用什麼就用什麼沒人可以管你，不過如果是在一個團隊裡面，勢必需要做出一定的妥協。

對於 startup 來說最有限的就是資源，有時候團隊空耗了很多時間在這些不重要的事情上面（從團隊能否存活下去，或是對使用者來說有沒有感的角度來看的話），最慘的莫過於都已經達成團隊共識了，最後還被推翻打掉重練…這真的不只是浪費資源，還嚴重的打擊了成員的士氣呀！

技術選擇

這是前一點的延伸。很多時候公司們的技術決策者會因為自己的喜好或是堅持而選擇了特定的工具或是技術，這可以理解，但是我覺得一個技術團隊還是需要擁抱開源軟體，要不然這對於日後的開發或是維護甚至是人才招募會有很關鍵性的影響。

為什麼這樣說呢？以我們為例，我們真的太專注在造輪子這件事情上面了。造輪子不是不好，在某個程度上他讓你對於使用的技術上有更多的掌控與理解，而且可以做許多更客制化的擴充。但是比起 startup，這件事情應該發生在有足夠資源的大公司會比較好，因為通常要維護這種輪子（特別是基礎建設的輪子）會花費大量心力，有時候為了業務需求還要做許多改變，所以如果你們是 startup ，光是專注在開發產品的資源都不夠了，更何況是這些對用戶無感的輪子呢？

第二個問題是社群的力量，就是因為沒有足夠的資源來做這些事情，所以如果選擇了知名的開源軟體當做基礎建設的輪子，那就可以搭著社群的力量前進，更專注在自己的產品上。

第三個問題就是招募還有職涯發展，一來是這類型的私有輪子會造成成員投注了太多時間在其之上，而沒有去研究或是了解市面上比較流行或是大家比較常用的技術（不是要一昧跟風，但是至少要花點時間了解大家在幹嘛），造成了未來職涯發展上的受限。而這個的另一面就是招募也會是一大問題，如果需要找新血來參與開發，基本上他們所擁有的能力是無法在第一時間帶來幫助的，通常還是需要經過一個不短的學習期才能實際上場，真的很傷。

所以如果可以的話，在捲起袖子開手寫第一行程式碼之前，想想這個問題，找找看網路上有沒有什麼現成的解決方案，真的可以幫團隊走得更遠，要不然中途才做改變帶來的成本真的很高很高很高！（真的很重要，所以要說三次）

權力下放

我想各個團隊的 CEO／CTO／C?O 應該都不是一開始就是做這些事情出身的，通常一開始都是專精於設計、資訊…等各個領域的專家，但是是因為公司編制的關係才掛上了這樣的頭衘。

如果初期團隊小，就只有這幾位創始人，那當然沒什麼太大問題，反正每個人還是繼續專精在自己的領域上。但是如果人數開始成長，開始招募了非核心團隊的成員之後，問題就開始了。

有時候上位者並沒有意識到自己職位的改變，沒有辦法適度的把權力下放給同樣領域的成員做決定（像是 CTO 授權給架構師、CDO 授權給設計師…等），而還是把決定權保護的好好的，就會造成上面的人因為要參與的事情太多所以忙得要死，而下面的人因為沒有辦法決定事情所以會浪費很多溝通的成本在說服能做決定的人，甚至是要花很多時間持續改動 spec 直到同意為止。大公司就算了，但是對 startup 來說真的是一大傷，通常這樣一來一往也過了好幾天了。

所以如果可以，請適度的鼓勵下面的人自我嘗試並授權給他們！

持續主動揭露訊息

對於一起在 startup 工作的大家來說，與其說是同事，不如說是戰友還比較貼切一點。比起穩定的大公司，要選擇在種不穩定的環境工作真的是需要拿出勇氣的，更不用說是那些有揹負家庭責任的人。

在海軍當兵的時候常聽到「同舟共濟」這個詞，我覺得也蠻適合用在 startup 這樣的環境。

不管是好的或是壞的消息，為了要讓大家不要有各種過度的想像或是猜測，最好的做法還是持續並主動地揭露訊息。真心覺得這對於實行遠端工作的團隊來說特別重要！

語言落差

我覺得這是在參與過由台灣人及非台灣人組成的團隊之後得到的感觸。以前在大公司上班的時候，同團隊成員之間一定會有著比較深厚的友誼，一定都會自己私約各種吃喝玩樂的活動，然後比較不熟的同事們就比較不會有什麼特別交集，也更不用說是和管理階層之間的互動了。

想想，光是講中文的我們之間都有著這樣子的落差了，更何況是和那些不是講中文的同事們呢？所以如果團隊是由講不同母語的人們所組成，最後通常就會變成兩個獨立團體，吃飯或是聊天都是各聊各的，大吐不快！！

所以如果今天你是老闆而你真的想要了解團隊成員之間最真實的內心話，或是想要和他們有最真實的互動，能夠了解他們所使用的語言真的是一大加分。

任務分配

身為一位工程師，解 bug 對我來說是比較乏味的一件事情。不過不可避免的是程式難免都會有 bug，所以這一定是日常工作的一部分，但是如果持續解 Bug 超過一兩個月而無法開發其他有趣的功能，那真的是會是讓人心情低落！

startup 的 CEO 有時候為了資金的問題而忙得焦頭爛耳，如果團隊裡又沒有相對應的管理階層可以決定未來產品方向，很容易就會陷入這樣的困境，因為沒有方向的話就代表暫時沒有新的功能可以開發，但是又不能讓整個團隊空轉，所以唯一的解法就是要求大家修 bug 或是改善效能，如此而已。

現在往回看，這件事情在當時真的實實在在的影響了團隊的士氣呢。

最後

很快的兩年就這樣過去了，2017/08/01 是在一個團隊兩年的里程碑，我們有歡笑、有爭吵，但是不管怎麼樣還是很高興認識了這群有趣的人，未來的路還很遠，還有各種無限可能。老樣子，想說的話太多，還是找個時間大家約出來喝喝酒聊天比較實在！

謝謝你們 🙂

(+Mehgan, Ratih, Vlad, Pomin, Lucien … etc)

vectr-2

數位游牧的生活（未？）完

[iOS] Compilation time goes crazy when using `+` in Swift

Image Credit

slow-656x330

Recently I have been working on one of my side project in Swift. Originally, everything looked fine, but not sure starting from when, the whole compilation process started to be slowed down a lot from 20s to more than 5 mins!!

Originally I was thinking it’s mainly caused by some of my 3rd-party libraries because I did install some new ones during that period. So as an engineer, I started to bisect and see what’s going on. But after uninstalling / reinstalling those libraries, things are not going well though.

Ok so it looks like this way is not working and not the root cause, so what’s next ? After thinking a while, I started to check codes line by line and see what’s the most suspicious part that can cause the problem.  TBH, there was no any piece of codes looking suspicious to me… Ok no ways to go again, the only thing I could do is to narrow down variables and started to comment out methods from entry point.

After a while, boooooom, I finally found the part which would cause the problem !!!!

螢幕快照 2017-08-03 下午2.31.27.png

What the hell, it’s all about + !! Because I mainly work things in JavaScript, it’s really not intuitive to me that this can be the problem! After googling around, here comes some comments about this problem :

Reference

 

It has to do with type inference. Each time you use the + operator, Swift has to search through all of the possible overloads for + and infer which version of + you are using. I counted just under 30 overloads for the + operator. That’s a lot of possibilities, and when you chain 4 or 5 +operations together and ask the compiler to infer all of the arguments, you are asking a lot more than it might appear at first glance.

That inference can get complicated – for example, if you add a UInt8 and an Int using +, the output will be an Int, but there’s some work that goes into evaluating the rules for mixing types with operators.

And when you are using literals, like the String literals in your example, the compiler doing the work of converting the String literal to a String, and then doing the work of infering the argument and return types for the + operator, etc.

If an expression is sufficiently complex – i.e., it requires the compiler to make too many inferences about the arguments and the operators – it quits and tells you that it quit.

I think I am too familiar with languages like JavaScript, so all the details like this are all hidden and not exposed to us. No matter how, it’s still surprising though. Hope in Swift 4, this kind of basic operations like Array concat can be optimized and boosted up.

[Nonsense] Just back!

Image Credit

lonely-man

Finally, after 1 year, I am back! It’s been a while not updating my own blog due to so many reasons. I did try to write down some words but always forgot to finish it. In addition to this, there are also some problems in the blog system itself so that I can’t even publish the post or update plugins.

Few days ago, I made a decision to migrate all my self-hosted blog to WordPress.com and pay for it. It’s nice to leave all weird problems behind to someone else and focus on writing contents. I am sure from now on, I’ll start to write more words down and share to the world 🙂

Although it’s kinda late, but I still need to say, goodbye 2016 and welcome, 2017 !

[Electron] How to codesign your Mac app

Image Credit

codesign

Introduction

Recently, Electron desktop application gets hot and popular among developers. It’s easy for developers to quickly mockup a desktop application and distribute it to three different platform with zero efforts ! (This is really a lie after I made another popular open source project called Kaku with the same tech.)

Ok back to topic, for companies who want to distribute their desktop apps to the world, they must codesign the application first ! The reason why this is important is because if you don’t do so, if the user enable gatekeeper by default, the application will be blocked due to unidentified developer and users will not be able to open it !

unidentified_developers

security_preferences_options

So in this article, I’ll try to share some my experiences about how to do the codesign for Mac app and what’s going on behind the problems.

TL;DR

Thanks to Marco Pracucci who wrote some useful details in his post, you can just follow these simple steps to do codesign :

  1. Get a Developer ID certificate from Apple and install it into your Mac’s Keychain
  2. Sign your application bundle codesign --deep --force --verbose --sign "<identity>" Application.app
  3. Verify the signature codesign --verify -vvvv Application.app and spctl -a -vvvv Application.app

Note: The identify here is the id wrapped inside the parentheses that you can get from keychain like the screenshot below:

keychain

But … the world sucks

The first problem I have encountered is version problem.

After codesign the app on my laptop (running 10.11.4) and share this app to my team members to test with, for those who are using 10.10.x, they will not be able to use the app and the gatekeeper’ll keep complaining something like the image below : 

vectr_damaged

But for the others who are using 10.11.4, the app is working well on their laptops (WTF???)

After googling a while, I finally found a discussion thread here on GitHub talking about this ! If you codesign your application on 10.11.4 , you’ll successfully get it codesigned and usable BUT for users who are using 10.10.x (to be specific those who use laptops <10.11.3) will have problems when opening that app.

From the discussion thread, we can learn that there are something changed from 10.11.3 to 10.11.4. If you want to hack that around by yourself, you’ll need to follow the steps here. But for me, I use electron-packager, so if you are using that too, you can just upgrade to 6.0.0+ because they already handle that for you on that version with zero efforts !

How to verify your app

  • codesign
    • This tool is not only for doing the codesign, but also you can use it to verify whether it’s well signed or not. After running it, you can get things like this :

  • spctl
    • For this tool, this is mainly used to see whether your codesigned application will be blocked by gatekeeper or not, if you didn’t get anything wording like accepted, your application will always be blocked or treated as damaged by gatekeeper, so it’s really important to use this tool to do the check every time when you create the new application.
    • Note: If you are using Apple Developer ID certificate to build you application and be distributed by yourself, Remember to change your [System] > [Privacy] to “Mac App Store and Identified developers. Otherwise, you will keep getting rejected information.

How to test

You can check details here from Apple’s documentations, but I’ll still copy some here.

  1. To disable Gatekeeper using the spctl command
    • $ sudo spctl --master-disable
  2. To confirm that Gatekeeper is enabled using the spctl command
    • $ spctl --status
      • If enabled, you will get assessments enabled
      • If disabled, you will get assessments disabled
  3. To test your Developer ID-signed app
    1. Make sure your gatekeeper is enabled by follow above ways.
    2. Email your Developer ID–signed app to yourself and use the copy that Mail downloads to trigger the dialog.
    3. Host your Developer ID–signed app on your own local or remote server and use the copy that Safari downloads to trigger the dialog.
    4. By doing so, your gatekeeper will be triggered correctly !

Troubleshooting

A) My certificate on keychain keeps showing expired

This problem is critical and annoys developers who are not familiar with Apple certificate things (like me !) When working on the codesign feature, I noticed that no matter how hard I re-install the certificate that I download from Apple, it will keep showing expired with no reason !

After trying and discussing this with one of my iOS friend, we finally realized it’s related to this notice ! For someone (not sure who, but including me), the Apple Worldwide Developer Relations Certification Intermediate Certificate is going to expire on Feb 14, 2016 which will cause the problem to make your certificate keeps expired.

What you need to take action here is to renew the this core certificate and try to re-install (or re-create) your developer certificate again and things will be solved … WTF !!

B) Where to find my certificate ?

For most of people, if you are writing desktop application by Electron, normally you’ll distribute your application by yourself (like us). But, I noticed that it’s really frustrating to figure out how to get that Developer ID Certificate !!

I have tried several times from https://developer.apple.com, but there is nothing related to Developer ID Certificate (or maybe it’s mainly because I am using different role, so it’s not showing up ?) ! After reading tons of articles, I finally realized that it’s inside Xcode !! You can check the screenshot below :

issue_certificate

But you can notice that the buttons are grey and is not clickable. That’s mainly because the role is wrong !! Even if you are admin role, you still can’t generate that ! Only Team Agent can do that ! So if you are developer or admin, Go ask your leader for that and tell him/her to press the button above to create the certificate for you.

After getting the certificate (it will be name like this xxxxxxx.p12), you can just double-click the file and install into your keychain. Remember, always keep them private 🙂

Note: Only the first one who made the certificate and uploaded to Apple Developer can have this .p12 file. This will only exist on his own keychain and you can’t even get it from Apple Developer. So remember to ask him to export that p12 file and share with the whole team ! Remember, if you lost this .p12 file, no one can save you and you need to regenerate another certificate again.

Last few words

It’s really a hard time to fight with codesign stuffs especially there are less resources talking about this. But whatever, I wrote them down already !! If this article does help you, please feel free to share !

And also, if there is anything wrong or missing in the article, feel free to tell me and I’ll update it ! See you guys next time 🙂

Reference

  1. https://pracucci.com/atom-electron-signing-mac-app.html
  2. https://github.com/electron/electron/issues/4899
  3. https://goo.gl/ZgKXr1
  4. https://developer.apple.com/support/certificates/expiration/

[Javascript] Something about pinch gestures

Image Credit

pinch-gesture

最近一直在研究如何在 Browser 上支援 Mac touchpad 的 Pinch 手勢，所以有一些心得想要記錄一下。

3rd party libraries

一開始的想法就覺得這種事情應該有什麼 3rd party 套件有支援了，只要簡單的把 event 和現有的程式接上就可以了。不過找了一陣子後，實在是沒有找到什麼好東西，通常大家推的都是 Hammer.js，不過其實這個 library 是專門設計給 mobile app 使用的，看了一下程式碼發現是組合 touch 相關的 event 後再經過數學運算後提供客製化的 gesture event 像是 pinch、pan … 之類的。

不過這個和我的使用情境不太一樣，因為 gesture 相關的 event 只有在 mobile 的 browser 上才會存在，因此只能再找找別的方法。

Solutions

之後很幸運的找到了 Chromium 開發者們的討論串，主要在討論的內容就是要如何把 touchpad 上的 pinch 手勢透過 wheel 這個 event 傳出去！那個討論串主要的重點就是在於 2014 年五月之後，Chromium 開發者們上了一個 patch，讓前端開發者可以透過正規的 wheel event （對了，wheel 和 mousewheel 有點不太一樣，前者才是大家公認的標準，後者則是非標準，只有少部分的 browser 有支援，要注意一下）去偵測 pinch gesture 的觸發。當 wheel event 是透過 pinch 觸發的話，那傳進來的 event 的 ctrlKey 這個屬性則會被設成 true，所以開發者們就可以用這個值來做判斷。

而在我們公司裡，因為我們要監聽這個手勢的發生做客製化的視覺處理，而且我們不希望 Mac 上預設的 zoom in / zoom out 還被觸發，所以要記得透過 event.preventDefault() 來避免 Browser 做 zoom in / zoom out 的動作。

Limitations

當然世界沒這麼美好，所以我最後還是整理了一些目前的限制（以後說不定就沒這個問題）

  • Safari
    1. 目前我手上最新的 Safari 9.0.x 版（Mac OS X 10.11.x）是沒辦法透過上面的方法來偵測手勢及取消預設的 zoom in / zoom out 觸發。
    2. 好消息是在未來的 Safari 9.1.x 版後，他們提供了新的 gesture event 讓開發者們可以去偵測手勢，不過這個版本目前也還沒釋出所以也沒辦法測試，如果官方文件沒有唬爛的話那就應該是可以支援，只是這個 event 目前應該也是 Safari only 的客製化 event 就是了，會不會變成 standard 也不知道。
  • Chrome
    1. 在 2014 年五月後的 Chrome 就支援上述做法來偵測 pinch 手勢了！（我很想查 Chrome 的版本號只是不知道怎麼找，如果有人知道那個 patch 實際被 land 到哪個版本的話，請和我說一下）
    2. 個人 Chrome 48+ 實測是 ok 的。
  • IE / Edge
    1. 如果討論串上的資訊正確的話，那 IE / Edge 應該和 Chrome 一樣有支援 ctrlKey 可以讓開發者去做偵測。
  • Firefox
    1. 無解 …
  • Electron
    1. 我有測試過 Electron 0.36.x+，因為他的核心也是 Chromium，所以這個做法也是可以支援的！
    2. 如果你是用 <webview> 的方式來載入你的 web app 的話，那你特別需要先在 render view 的地方聽  wheel event 但是不需要做任何事（超怪，無法理解），這樣這個 wheel event 就會正確的被傳進你的 <webview>，然後你的 webview 裡面如果有實作 event.preventDefault() 的話，那預設的 zoom in / zoom out 行為就會被取消，這樣你就可以在 webview （也就是你的網站裡面處理這件事情就好）

References

附上所有我找到的有用資源如下：

  1. http://jsbin.com/qiyaseza/8/edit?html,css,js,output
  2. https://bugs.chromium.org/p/chromium/issues/detail?id=289887
  3. http://stackoverflow.com/questions/15416851/catching-mac-trackpad-zoom
  4. http://stackoverflow.com/questions/29929411/disable-pinch-zoom-in-webkit-or-electron
  5. https://gist.github.com/NekR/9a80ebe73573e11f0351

[Look Back] 2015 – A Crazy Year

This image was made with Vectr

look-back-2015

時間過的好快，2015 又過了呢 … 已經來到傳說中的 26 歲了呀。

逝去的 2015

過的好快，2015 就這樣過了，來列一下年初期許的事情有哪些完成了：

  1. 背好五十音 xD
  2. 挑戰一個人去旅行，學著和自己對話。
  3. 勇敢離開自己的舒適圈。
  4. 不要一個人過完這一年。（閃屁）

如果真的要說，2015 真的是一個瘋狂的一年。

工作方面，在七月的時候離開了 Mozilla，謝謝前同事們對我的照顧，在這個地方學了好多東西，然後又來到了另一個有趣的地方 Vectr ! 不只開啟了數位游牧民族的生活，也開始實作一些有關繪圖軟體需要的東西，這個經驗真的是很難得呀。

感情方面，雖然在 2014 年尾發生了一些事，但是卻又遇到另一個更好的人，也因此催生了 2015 年最重要的 Open Source 專案 – Kaku！也開始在師大學日文，不知不覺也上了一年的課，日文能力也略有進步，雖然在日本的時候只會講不會聽也沒什麼屁用就是了 xDD 只能繼續加油。

而在旅行方面，這一年也跑了好多地方：

  • 金沢
  • 高山
  • 白川郷
  • 大阪
  • 奈良
  • 清邁
  • 拜城
  • 澎湖四天三夜
  • 四年一度的東港燒王船
  • 台南遠端工作一週

還記得以前曾和旅行咖的朋友說過日本是我們 50 歲以後才會去的地方，沒想到這一年我們兩個都去了日本，而我還去了兩次 xDD。邊打這篇的時候還邊翻了一下行事曆，才發現原來我跑了這麼多地方！旅行對我來說真的是生命中不可或缺的一環呀。

現在進行式的 2016

這一年我想試試看不要預先設定目標，試著讓時間的推移來開啟更多不同的可能性，很多時候人生就是在這種時候才會發生許多精彩的故事不是嗎！？

最後還是要謝謝在 2015 年出現在我生命中的所有人，不論是好是壞都是讓我繼續前進的一部分！謝謝你們，一起加油吧 🙂

[Memo] 數位遊牧的生活 Part 1

Image Credit

digital_monad

前言

從七月離職後就一直想寫一篇有關「數位遊牧民族」的生活，但是一直被拖稿（？？）真心覺得這一段旅程應該會是人生中特別值得紀念的一部分，所以要好好的寫些東西來記錄一下！

起點

我想，所有的起點都是從 2014 年這封信開始的吧：

beginnings

真沒想到我還翻的出來這封信，對我來說，這封信是目前職涯的轉折點（加現在這裡也才第三間公司，職涯是有多長啦 XD），也是我數位遊牧生活的起點。

想想，我開始認真學「寫」程式，應該是我在大二的時候吧，那個時候因為社群的關係認識了一些人，一起做了一些有的沒的的小專案，雖然沒賺多少錢但是不知不覺中也建立起寫程式的熱情還有能力。又因為當時認識的朋友們給了我很多機會，所以也在各個地方遊走了一些時間，又從中認識了好多人還有提昇了一些能力。

大學畢業後，我就設立了一個目標，就是每一年至少要寫一些有趣的開放源始碼專案，先不管這些東西對別人來說有沒有用（有用當然最好），但是至少要寫一些東西出來。久而久之，我的 GitHub 開始累積了一些東西，而之中還真的有人在用 XD （我都不敢用了你們怎麼敢用！！？）。其實當初在寫程式的時候也沒想這麼多，主要也就是好玩而已呀（玩心 driven development xD），天知道這竟然會是日後和 Nick 接上線的橋樑！

不過管他的，「機會」就是來了，想擋也擋不住。

Let’s talk

這邊真的要特別講一下，我真的覺得外國人找人的方法很特別（樣本數只有一，應該很不準 xD），有別於以往在 LinkedIn 上面的罐頭信，Nick （我們的 CEO）的做法就真的很不一樣，從上面那封信其實就可以看的出來如果他們對於你這個人有興趣的話，他們會先試著了解你這個人做過的所有事情不論是技術或是非技術相關的。以 Nick 為例，他的做法是上 GitHub 把所有在台灣的 JavaScript 開發者從頭到尾全部看一遍，然後從你的作品去了解你這個人的能力在哪裡，如果對你有興趣的話會再透過你在 GitHub 上面留的信箱來聯絡你，對你做進一步的認識。

補充：這裡有兩件事情我覺得很重要，一就是 GitHub 對於一個軟體工程師帶來的影響，二就是你一定要留一個別人找的到你的信箱，如果怕被機器人找到你的話就把 Email 的特別字換掉也是一種不錯的做法。所以如果想要和國外工作機會接軌的話，麻煩參考一下這段。

在初步的 Email 往來後（約十幾封 xD），就和 Nick 約了某天去士林吃夜市。我覺得對他們來說，實體接觸似乎是一個必要的過程，它提供一個無壓力的環境介紹（推銷）他們想要做的事情給你，也會從中和你聊許多有的沒的事情，從技術、工作、玩樂一直到生活層面都有。簡單來說，我覺得 Nick 這個人給我的感覺是除了找員工之外，還多了一種交朋友的味道在裡面，你唯一要特別注意的事情就是用英文坦住 4 個小時以上，並且試著用各種方法騙他們吃一些奇怪的東西像是「豬血糕」、「臭豆腐」或是「皮蛋」就可以了 XDD

不過說真的，我們約出來的次數應該有超過 2 ~ 3 次以上，而且每次的時間也都頗長，畢竟對一個 Startup 來說時間還有資源怎麼樣都是比大公司還受限呀，所以多花一點點時間找到對的人相對就重要許多了，那過程相對耗時也就可以理解了。如果硬要算的話，我覺得在這些過程上所花的時間真的比我過去面試（也才兩間而已是在大聲什麼 ）過的公司還長許多呀。

遊牧的生活

vectr-2

終於來到這篇的重點「遊牧生活」了！

對我來說，我覺得如果沒有經過第一份工作離職後那短暫 3 ~ 5 個月和室友在家自己寫程式的時候，我想遊牧的生活對我來說是一件非常困難的事情吧！還記得那個時候的我們對於離職自己創業（玩耍）有著一些憧憬，剛好前後我們都遇到了跳潮的時候，就順理成章的在家自己開著電腦工作。

那幾個月是一年中最熱的時候，而我們每天都在悶熱的頂樓加蓋中幻想著不存在的未來。雖然我們沒有錢、沒有可以賺錢的想法什麼都沒有，但每天我們還是很樂天的朝著自己夢想中的方向前進。

不過想也知道這怎麼可能賺錢，到後面其實都是在用自己的老本來付房租還有生活費，存款也不知不覺中快見底了，而最後也不得不去接一些 Case 來試著養活自己，步調也就從此亂掉了。不過事後想想，我覺得這些事情都不是最難的，最難的事情其實是維持「規律的生活」還有「自制力」。而很剛好我們就是沒有自制力的那兩位，很常每天都睡到中午、想做事的時候就做事、想睡到的時候就睡覺，生活和工作再也此分不開來。而當然爾，最後這場鬧劇也就不了了之，我和我室友也各自另尋出路去了新公司工作了。

所以，有了過去的慘痛經驗，我對於第二次的遊牧生活就有許多心理建設了，要用和上班族的態度一樣有正常的上下班生活，每天盡量十二點附近睡覺、早上九點起床開始一天的工作，然後六點多之後則是回歸自己的生活。切記，適當的把工作和生活是數位遊牧民族很重要的一件事情呀！

回到數位遊牧本身，我覺得這個工作帶來最大的好處就是「健康」還有「有更多的彈性去體驗這個世界」，以健康來說，我幾乎每兩天就會跑去游泳或是在家簡單的做一些運動。以前七點下班，搭車到家已經八點、吃完飯都九點了，還來其他的時間去運動，雖然還是會盡量播空逼自己先運動再吃飯，不過運動完後吃飯的時間也都九點多了，其實也沒有多健康就是了呀，囧。

而另一個好處就是關於彈性這件事情，因為大家都是遠端在自己的工作環境工作（家、咖啡廳…），所以大家並沒有很在意你人現在有沒有乖乖的待在座位上，只要個人負責的部分有所進度就夠了。因此很多時候，在快接近下班時間或是有點腦部缺氧的時候，我就會拿著我的游泳包去附近的泳池游個泳，因為通常很多時候坐在那邊也沒什麼意義，頂多就是繼續卡關而已呀！但是如果是在辦公室，有時候還是會很在意所謂的「下班時間」，沒有到那個時間之前離開的話都像是犯了淘天大罪一樣，那在這個風氣之下，其實也就很難這麼隨心所欲的說走就走了。

Vectr-ers

vectr-1

由左至右分別是 Nick 、Hychen、Yurenju、Emery 、 EragonJ
（雖然當時 Nick 人在國外，但我們還是請朋友硬是把他 Vectr-ed 進來 XDD）

（這篇文寫太長了，快轉鍵給他七略！）最後，我就告別 Mozilla（謝謝你們！）來到 Vectr 啦 😛 其實這也小小的圓了我想在外國工作的夢想呀（不是人在台灣嗎！）。以前雖然是在 Mozilla ，但是其實在台灣的人也都還是台灣人，說衝擊嗎其實也沒有很大的感覺，大家都是在網路上打打字、留留言比較多，也沒有什麼實際一起共事的機會。不過來到 Vect 就不太一樣了，也才只有五個人而且要打理所有大小事（還好我只要刷我家的馬桶就好），再加上我們每週定期有一次實體會議，所以其實大家接觸的時間真的蠻長的。而每次只要大家聚在一起的時候，我們三個台灣代表都要開啟全英文模式至少 4+ 小時以上，通常要一直到最後大家都元氣耗盡了才會結束 XDD 真的是一種很特別的體驗呀！

在這邊有很多新的東西可以學，也有很多機會和不同的人一起工作。對我來說，跳出自己的舒適圈只是第一步，數位遊牧生活也才剛開始而已，未來會怎麼走我也不知道，其他的就留到下一篇再說吧 😛