[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.

[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 像是 pinchpan … 之類的。

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

Solutions

之後很幸運的找到了 Chromium 開發者們的討論串,主要在討論的內容就是要如何把 touchpad 上的 pinch 手勢透過 wheel 這個 event 傳出去!那個討論串主要的重點就是在於 2014 年五月之後,Chromium 開發者們上了一個 patch,讓前端開發者可以透過正規的 wheel event (對了,wheelmousewheel 有點不太一樣,前者才是大家公認的標準,後者則是非標準,只有少部分的 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 年出現在我生命中的所有人,不論是好是壞都是讓我繼續前進的一部分!謝謝你們,一起加油吧 🙂