你是否曾相信過,在煙霧之上有星空的存在?

『映画 えんとつ町のプぺル』予告1【12月25日公開】

今天久違的和日本柔道朋友跑去大阪難波看了是一部由西野亮廣所製作的一部名為「えんとつ町のプぺル」的動畫電影,想說可以寫個文章和大家分享一下!不過我查了一下發現目前這部片只有日本有在播,所以也沒有中文譯名,那就估且讓我稱它為「來自煙囪霧都的布培魯」吧!(為了不向大家暴雷,下面我已經避掉了所有有可能暴雷的資訊 XD 請別擔心)

柔道友人和電影看板的合照 xD

說實在的我個人其實很不愛花錢去電影院看動畫電影,但是因為朋友的熱情邀約所以就只好赴約,原本真的不預期說會有多好看,誰知道電影看到中後半段就在親情、友情交織的情感攻擊之下落淚 XD 真的是和我原本想的完全不一樣呀!!如果這部動畫有機會在你居住的地方上映的話,真的推薦你去看一下!

你是否曾相信過,在煙霧之上有星空的存在?

這部電影雖然叫做「來自煙囪霧都的布培魯」,但其實布培魯指的是主角小男孩身邊的那個機器人,而主角小男孩的名字則是叫「ルビッチ(魯比奇)」。整部電影其實是以小男孩生長的煙囪霧都為故事核心,因為一些原因所以意外的交到了他人生中的唯一的朋友,也就是機器人布培魯本人。

因為這個城市煙囪林立,所以整個天空其實是被骯髒的煙霧所遮蓋住的,而長期居住在這裡的人們也因為從小都是在這個環境下生長,所以也理所當然的認為這個世界就應該是這個模樣。但是因為主角魯比奇的爸爸,曾經在路上的某個角度看到了煙霧之外的一顆星星,又還意外地在在酒吧從不認識的居民們那邊聽到了有關煙霧之外的鄉野故事,因此深信著在煙霧之外的世界裡是有星星的存在的,也因為自己樂天的個性所以到處在路上和來往的人們分享這個故事。

但很可惜的是,人們終究不會相信自己沒親眼看到的東西,所以父親本人反而被大家視為異類份子,被各種排擠甚至是無視,同時也間接的影響到了主角小男孩的生活及交友圈。在一次的意外之後,雖然主角小男孩失去了爸爸,不過他還是堅信著煙霧之上的天空是有星星的存在的,所以他就和他最好的好朋友布培魯展開了一趟冒險旅程以向霧都的人們證明這件事情,而這也就是整個故事的主軸。

Image Credit

↑上 Amazon 買個動畫的畫本回家看看

這部片雖然看似是一部為小朋友們所做的動畫電影,但其實看了之後會發現作者其實透過各種隱喻的方式傳達了很多很深的訊息在這部片裡面。

從一開始的霧都的設定還有人們只相信這個自己所居的世界來看,也傳達出了一種這個世界上的人們都隨波逐流的訊息。當每個人都不再對事物有所質疑或是有試著勇於去改變現狀的勇氣之後,大家就像是生活在一灘死水(霧都)裡一樣,毫無生氣。

但是很諷刺的是,當人們的身邊出現了那麼一位試著想去改變現狀的人物(男主角魯比奇或是他的爸爸),對這個群體的人們來說他就會是一個相當突兀的存在,因此就會開始出現各種言語罷凌、動手動腳等情況,試著透過這些方式來排除掉這些不定的因子,然後讓這個世界又再次回到了原本的波動下,如死寂一般。在台灣有一句很經典的名語是這樣說的:

與其解決問題,還不如解決提出問題的人

真的是很有異曲同工之妙呢。

最後,在結束前,想和大家先分享一下這部動畫電影的片尾曲「ロザリーナ『えんとつ町のプペル』」:

ロザリーナ『えんとつ町のプペル』

大家看到這邊,也能夠思考看看自己是不是也有這個狀況,已經對於生活週遭的事物感到麻痺亦或是深陷在有如爛泥般的死水裡呢?如果可以的話,在自己能力所及的範圍內,試著和男主角魯比奇一樣勇敢一波,去尋找看看煙霧以上的星空吧 🙂

我們下次見!

P.S.  如果對我在櫻花國的生活感興趣的話,也不妨看看一下我有在持續更新的社交平台 FacebookYouTubeInstagram 吧!

你的人生不是你的人生

參考圖文出處:https://www.facebook.com/krenz.krenz/posts/2630024330367686

今天看到朋友在 FB 動態分享了一篇 Krenz Cushart 大所寫的一篇文章,大意是說到每個人在人生的各個階段裡實際上可以自由使用的時間有所不同,會隨著你年紀的增長而逐漸下減,也代表著你可以使用的自由時間其實在每個階段裡其實有著不同的價值。

不知道為什麼這麼巧,在看到這篇文章之前,我剛好又先在 Inside 上面看到一個文章在講過度工作造成過勞死的事件,而標題是這樣寫的:

中國電商拼多多 22 歲員工猝死引爆輿論
央視:奮鬥非拿命換錢

這兩個文章搭配看了之後,對於正在日本當台勞打工族的我有點小小感觸呀… 在日本工作的時候,總是會發現有很多日本同事都會加班加到很晚,沒日沒夜的一直在工作,不知道到底是整個社會帶來的壓力還是個人使命感太強,已經把這件事情內化成一種生活模式,週一到週五都是以這樣子的模式一直在燃燒自己。

對於這類人來說,工作已經不是職業而是一種志業了吧?當然也就不會有什麼「加班」的認知,因為從以前到現在就是這樣子做過來的,如果沒有維持好這個模式,反而很有可能會被同事貼上「不認真」或是「沒在做事」的標籤。更不用說為了維持它,在日本絕對少不了的「飲み会」更是一定要去參加,沒喝到個第三輪不能回家之類的 xDD

這邊一定要講一下我也有經歷過這一段,但是我就是屬於很懶又不會讀空氣的死外國人,以前被約過幾次要去喝這種攤我幾乎都用各種理由閃躲,閃個幾次之後也就再也沒人會來約了。阿不是呀,到底和(不是那麼熟)的同事們去喝到掛到底有什麼好玩的,回家看鬼滅之刃或是 Sweet Home 不是更有意義嗎!?(大誤)

Sweet Home 是從 Webtoon 改編的驚悚劇!我先看漫畫再看劇的真的超好看!推薦給大家!!

回到原文,不知道大家有沒有好好的去檢視自己的每一天,在上下課、上下班之後,你有留了什麼時間給自己嗎?我覺得很多人,當然包含我(雖然我自己不這麼認為 XD),其實很多時候都是「活著」,恩,但是也就只有「活著」而已。雖然很多人常常覺得我一直在講「夢想」是老生常談講到爛的一個虛幻的東西,但是至少對我來說,就是因為有「夢想」這個動力才能支持我走到現在。

回首大學四年、畢業當兵、出社會直到 2021 的這個當下,幾乎每一年的日子裡總是會有那個幾個很主要的「夢想」會去完成,然後為了完成它們,在這個途中自己也成長、得到了很多。像是為了和工作人員有聊天話題這個動力,所以我開始自學日文,又去上了日文課,最後去了櫻花國的關大留學(出國讀書一直是我人生夢想之一!!),最後跑來日商工作,這中間也為了自己寫了一些日文 app,也順手為了讓台灣的親友團知道我還活得好好的,所以和朋友一起拍些 YouTube 小短片來記錄生活,也就一直走到了現在。

這樣的生活模式,雖然累但是卻異常充實,在他人的眼中可能會覺得到底是在浪費時間搞這些五四三幹嘛,不過對我來說,如果只有上下班、上下課的人生的話,我想我應該是沒有辦法撐到現在這裡的吧我猜。

最後,雖然不知道有誰會看到這邊,但是在文章結束前,我還是想丟出一個問題給自己也給正在看這篇文章的你一起想想:

你的人生,是不是你的人生?

(我要來去健身啦)下次見 🙂


P.S.  如果對我在櫻花國的生活感興趣的話,也不妨看看一下我有在持續更新的社交平台 FacebookYouTubeInstagram 吧!

全新的 2020 ,不一樣的自己

雖然沒有特別講,不過我覺得自己有一種很特別的特質,就是每一年都會試著去做至少一件自己覺得很有挑戰性的事情。我覺這應該和我一直很容易不安於現狀這個個性有關係吧…

  1. 2017 年為了讓自己把日文學好,人生第一次寫了 3 個自己的 iOS app
  2. 2018 年趕在 20 代的尾巴勇敢辭職一波來日本關大讀了一年書,回到了學生時代
  3. 2019 年開始試著用影片把這些故事記錄下來,也和朋友一起在影片創作這一塊下了很多工夫,最後也跑到日本公司工作

但是 2020 呢?

我從 2019 開始就一直在思考我到底想做什麼事情,而其中我發現了一件有趣的事情。當初 2015 ~ 2017 附近為了學日文,所以意外的加入了台灣人和日本人組成的龍舟隊伍,一開始的想法很單純,根本才不是划什麼船,而是想找個有日本人的環境來練日文,如此而已。

結果誰知道,過了一陣子卻開始建立起運動的習慣,所以從開始划船到現在,我都不中斷的一直有在運動健身,算是一個學日文之外的收獲吧?從來沒想過自己會因此跳進去這個世界裡,像個瘋子一樣。

斷斷續續健身健了幾年之後,開始覺得自己都是去健身房盲練,看到什麼機器就用一下,在有限的時間內把一輪機器都掃過一次就覺得好像很厲害,什麼部分都鍛練到了所以應該很有效。

well,對於新手來說一開始還真的蠻有趣的,因為從 0 到 1 就是一個很大的躍進,比起什麼都沒有,當然可以在很短的時間內看到效果及體態的改變,不過相對的在一兩年後感覺就陷入了一個停滯期很難有所長成。

挑戰與改變

大家應該有注意到,在 blog 的最上面有個「健身日記(暫時失效)」的部分,點下去可以看到我開始用手機 app 記錄健身的各種資料,而這個就是一切的起點。自從開始有點系統的把數字記錄下來之後,可能更清楚的了解到不同日子、不同重訓部位的各種狀況。

雖然有了這些,但我發現還是很不夠,我需要真正更有系統性(科學化)的學習來幫助我進步,而不是和以前一樣隨便練練而已。因此就在前幾天我下了一個 2020 的勇敢決定「報名考一張健身教練的證照!!!」

截圖↓

真的很衝,541 USD = 16193 NTD 真他X的有夠衝,原來有錢人亂花錢是這種感覺 (大誤)。對我來說重點根本不是這張證照,而是一個能夠讓我前進的動力,所以我覺得藉由準備這個證照考試的過程,我可以更有系統的去學習人類這個物種的各個肌肉組成、各種訓練系統還有其他里里扣扣的知識。這些都是自己盲練了這幾年後發現缺乏的東西。

不過雖然說是盲練,但是我覺得至少我還是從中建立起了運動的習慣還有興趣,比起虛幻的程式碼,我覺得這種能真真實實影響一個人的東西才是我更想要的。

2020,應該是個精彩的一年 🙂


P.S. 此文寫於 2020-01-16!

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

https://gist.github.com/EragonJ/cc16613280384b0bf4bda36f1e761171

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

https://gist.github.com/EragonJ/36f31b2b1f0659e95ef4fdab6b2e9a02

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 年出現在我生命中的所有人,不論是好是壞都是讓我繼續前進的一部分!謝謝你們,一起加油吧 🙂