Just My Life & My Work

Posts tagged ‘illustration’

失業給付與提早就業獎金

新工作邁入第五個月,想起失業給付在就業超過三個月後,已能夠申請提早就業獎金。我是使用Mac上網使用自然人憑證,在網站申請:勞保局網站-個人網路申報及查詢作業。也下載勞保局行動服務App,來查詢當前審核進度。

時程記錄如下:

  • 3/3:申辦
  • 3/4:核定
  • 3/12:核付
  • 3/15:匯款

很好~勞保局E化作得讓我用的很方便!

(繼續閱讀…)

[iOS] iBeacon偵測多個Region

過去我所想的點子,只要偵測到iBeacon就進行對應事件。這次幫朋友阿強實現點子,發現同一UUID的iBeacon,只會觸發一次didEnterdidExit,用圖示來說明比較清楚~

可以看到兩顆iBeacon重疊偵測範圍,只要偵測到其中一顆,就只會觸發一次didEnterdidExit。這與Android測試得到的結果不同,iOS已經幫我們處理好,再把處理過的結果回傳給開發者使用,這是限制也是方便~

Android會觸發兩次(每顆iBeacon各一次),可能也叫做didEnterdidExit。阿強測試比較過後,發現iOS偵測速度比Android慢,這其實是因為iOS SDK會有數秒鐘偵測週邊iBeacon並處理。

(繼續閱讀…)

[iOS] iBeacon背景偵測流程

半年前在幫朋友阿強研究iBeacon,發現iOS在這方面比Android限制還多!首先來看iBeacon背景偵測流程,是跟前景偵測有何不一樣?

App在前景時,會陸續觸發三支APIdidEnterRegion、didRangeBeacons、didExitRegion,如上圖從時間點A到時間點B。

(繼續閱讀…)

[圖解] 軟體工程師離職後

去年還在健康科技公司上班時看到這張圖解軟體工程師離職後,還覺得是個開玩笑的狀況,沒想到終於被我遇到啦⋯⋯

曾經有聽說過,某新創公司的產品是由超強老闆寫出來,上線營運後發現市場接受度相當高,有意擴張規模而雇用幾個工程師來承接他之前寫的產品,這是我朋友吉米的前公司做博弈軟體的故事。

產品創始人把心中的想法迅速時做出來,透過雛形來測試市場接受度有多高,開發軟體過程想必不會寫得很有彈性,因為「彈性」是需要大規模超仔細地想各種可能發生的情況。比如若我當初只想要搞定80%的狀況,大概一個月就能做出來;若我要再觸及剩下的20%,可能要再多花兩個月才能完工。於是乎我會選擇前者!

當驗證市場可行後,接下來就來補剩下的20%。然而儘管只是20%,想要在既有的架構上可就不太容易擴展,而老闆僱用來的工程師肯定不可能全盤了解當初寫的架構與流程,因為裡頭包含各種Features、Bugs、User Cases、Work Flows、Workarounds等。加上老闆所展現的Coding StyleLogic,與雇用來的工程師所使用的並不一致,導致剩下的20%由老闆來寫只要兩個月,而若讓雇用來的工程師來寫的話就高達半年⋯⋯

回想我還在健康科技公司時,是如此呼風喚雨,iOS App由我一個人獨自從無打造出來,後進來的Android工程師都要仿照我的方式來實現,畢竟小而美的創業公司資源不多,要盡可能使用最少資源來達成目標。對比現在港商的工作狀況,產品已經由資深同事開發10個月,架構是由他建立起來的「樂高系統」,MVC架構非常分明,就好比我當初使用MVP架構HiLife App,然而相對的所花費的時間變多。

過去一個大功能我能在一天內完工,現在一個小功能我可能一天內還無法安心動手,落差非常大啊⋯⋯有時候真的想要不管既有架構,把可運行的Code塞進去,馬上就可以有正確的效果,只是長久來看,只會不斷增加「技術債」,這我在圖解理想與實際的軟體架構有提過。

想起我偉大的前同事德叔說:

要Refactor他人寫的Code需要很大的氣度。

我在下方回答笑說:

我寧願寫Code給別人Refactor,也不要別人寫Code給我Refactor!

對我來說,加入新創公司就是想快速成長,要像個成長駭客一樣跟著產品進化,來盡可能獲得較多的成就感!最終實現自我~

於是乎,之後若要我選擇的話,我肯定會選擇從「無」開始打造產品,因為我可以根據當時的規格(畫面、功能、流程等)來決定架構,可以很快就把既定的藍圖實現出來。

我心中有好多Idea要實現啊⋯⋯

[iOS] 應用程式的生命週期 (App Life Cycle)

先前已經了解過視圖的生命週期 (View Life Cycle),現在來研究高一層級的應用程式的生命週期 (App Life Cycle)。開發超過六年(從2012年開始)iOS App的我,儘管已爐火純青可以隨意開發一款iOS App,然而再習以為常的開發過程,一定還存在些我不太熟悉的細節!套句郭台銘的霸氣台詞「魔鬼藏在細節中!」所以若能透過圖解的方式來更理解兩個生命週期,想必能研發出品質更好的iOS App。

(繼續閱讀…)

[圖解] 理想與實際的軟體架構

理想與實際會有非常大的差異,在軟體界更是尋常可見!可是因為軟體並非實際的物品,所以通常不易讓「外行人」了解!不過當你看到這張圖解理想與實際的軟體架構,就能大概知道開發一個軟體將有哪些狀況會發生。

此圖取自IT狗的俄羅斯方塊,很高興這張圖寫實地描繪出我所經歷過的狀況XD~

軟體界所謂的規格(Specs),以我過去的經驗來看,大致只有在初期開發時管用,新的技術、新的需求、新的人事物⋯⋯都會影響啊~

我常笑說,我寧願從無開始打造,也不想要去維護他人遺留下來的「毒(技術債)」。

(繼續閱讀…)

[圖解] 2018年如何投公投票

2018年的九合一選舉公投比往年熱鬧,據說是因為公投門檻降低,使得這一次公投有10個議題,奇妙的是從7號到16號,為何不是從1號開始呢?原來是以往年累積到現在的編號,過去公投累積也才六個議題,可見門檻降低對公投「加熱」許多。

歷史上的6個公投案為:

  • 2004/3/20:強化國防,投票率43%,未通過。
  • 2004/3/20:對等談判,投票率42%,未通過。
  • 2008/1/12:討黨產,投票率25%,未通過。
  • 2004/1/12:反貪腐,投票率23%,未通過。
  • 2008/3/22:台灣入聯合國,投票率34%,未通過。
  • 2008/3/22:務實返聯,投票率33%,未通過。

可以從焦點事件這張圖清楚知道規則轉變~

 

今年(2018)下半年,除了地方公公職人員選舉外,引起全國關注的就是「公投」。2003年12月31日《公民投票法》施行以來,台灣共舉行過6次全國性公投,但都因投票人數不到總投票人數2分之1門檻,而未通過+ 。但在2017年12月12日《公投法》修法後,全面下修提案、連署、通過的門檻。「公投」一詞沉寂10年,再次現身,便是百花齊放。

那到底有哪些公投?接下來看十個公投的簡介⋯⋯

(繼續閱讀…)

標籤雲

%d 位部落客按了讚: