分類
About Mike

Rails 6 setup on Mac M1 (Big Sur 11.2.3)

最近試著用比較新的蘋果M1晶片電腦去跑Rails專案,光是設定上就踩到不少的雷,網路上也沒有相同的設置解法分享,自己簡單的紀錄一下,不過如果是跑最新版的各種軟體,我相信應該M1都有支援不會遇到這麼多雷。

Requirement

在Mac M1 BigSur 11.2.3 上跑 Ruby on Rails 6 with Ruby version 2.6.3 and MySQL 5.7

首先,第一步絕對不能錯,這步錯了後面怎麼設定可能也設定不好;在Mac terminal上要使用 “Open Using Rosetta” 來開啟並作後續的安裝。

在terminal上按右鍵,點擊Show in Finder
點擊 Get Info
勾選 Open using Rosetta

後續使用terminal安裝ruby-build就不會遇到問題了,不然光是安裝ruby-build我是怎麼裝都有errors…

再來是安裝Ruby,雖然系統已內建 Ruby2.6.3 ,但這個版本的Ruby跑在m1上會出現各種packages gem error,所以至少要使用2.7.2版,如果你可以用2.6.3跑,拜託拜託讓我知道怎麼設定。

安裝Rails比較不是問題,基本的gem install指令即可:

gem install rails -v 6.0.0.0

最新版的 node V16 也是會有一些packages尚未有支援m1的錯誤產生,建議使用 nvm來做安裝使用 v14 即可,詳細安裝方式網路有很多教學,這邊就不多做介紹。

最後由於專案是使用MySQL資料庫而非多數Rails開發者使用的PostgreSQL,加上Mac M1預設安裝好的MySQL版本是8,現有專案的資料庫轉移會出現一些問題,於是必須要降級 downgrade to 5.7,我嘗試了各種安裝MySQL 5.7版本的方式,不管是系統安裝、homebrew安裝全都失敗,不是裝了但無法啟動,就是裝一半會有makefile issues,最後解法是用外嵌於系統上的資料庫來解決:MAMP to the rescue!

https://www.mamp.info/en/downloads/older-versions/

剛剛好MySQL的版本是5.7,透過 mysql2 gem來做bundle後,修改database.yml裡的socket連線設置即可完成Rails的設定。

development:
  -- 其餘略過
  socket: /Applications/MAMP/tmp/mysql/mysql.sock

以上分享,總體來說M1跑起來的確是快非常多。

分類
About Mike

回顧 2019 工作上的新學習

農曆新年剛過,祝福大家鼠年鈔票鼠不完(完全硬搭),近日剛好有些空檔回顧一下去年在工作上新的學習,雖然常抱怨大公司做事效率很差,但仔細回顧發現其實在技術上仍然有所精進,以此篇文章作為未來回首的索引。

畢業後開始做網站工程師做了將近8年,從小型官方形象網站到中型資料庫網站甚至是幾萬人在線的售票網;從後端撈資料的工程師到開API進而到網站部署、做快取、自然擴充(Auto scaling)到前端頁面美化特效(CSS, SCSS, JAVASCRIPT)、SPA(Single page application);從菜鳥工程師到人稱所謂資深工程師;網站開發相關的問題大大小小即便沒做過,大概也知道要怎麼解。

2019年7月從高速成長的新創公司換到了上市公司,每週要處理的bugs與features從數十個變成個位數個,數字上看起來好像很閒,其實也不然,因為大公司產品的規模大,不管是使用者人數、同時在線人數或者是程式碼(code base)本身都在一個相當高的量級,架構與組織的複雜度無法與新創比擬,同樣解一個bug的effort可能比新創高出許多,自然能解決的數量看起來就不那麼壯觀。

回到正題,目前服務的公司是做資安的,公司主力產品是一個防火牆,我們組負責的是防火牆的設定網站(portal)。聽到這裡應該覺得很無聊對吧!?不要懷疑,我跟我們組老闆(manager)聊過架構之前我也是這樣覺得,但加以理解後,才知道要處理的問題其實很有深度,甚至其他公司可能無法碰到這樣類似的問題。

工作職務上,我負責的部分除了前端UI外還包含了nodejs的middleware,某種程度來說也算是在做Full stack。

故事要先從防火牆說起,防火牆的設定說穿了就是一堆欄位去對應實體的機器,舉凡SDWAN、Data lose prevention 、Symmetric Routing等相關的網路功能都可以在實體機器上設定。那這樣的欄位一個防火墻有幾個?公司身為新一代的防火牆領先者,功能自然多到難以計算,相關能設定的欄位在數千的量級,那至於開發此portal網站的目標是什麼呢?是做出一個不管防火牆端新增了什麼欄位功能,網站端都可以自然生成對應的欄位介面。

認識schema

Schema基本上就是一個檔案紀錄了一台實體機器上的所有欄位。用網站工程師比較好了解的語言來說的話,可以把schema檔案想像成一個xml檔案,內容記載了所有欄位的屬性(attribute)與階層子母關係(parent child relationship)。每一次防火牆的更新都會有新的schema產生,可能多了欄位或是少了欄位或者是有什麼欄位做了更動。

舉例來說:(schema範例)

<?xml version=”1.0"?>
<sequence name=”config” forward-compatible=”no”>
  <sequence name=”demo-config” optional=”yes” xpath=”/config”>
  </sequence>
  <array name="users" optional="yes">
    <sequence name="entry" tlo="yes">
       <validate expr="not(@name='root')" err="'root' is a reserved name"/>
       <validate expr="not(@name='machine')" err="'machine' is a reserved name"/>
       <validate validator="not-system-user" err="it is a system user name"/>
       <attr-req name="name" type="string" regex="^[a-zA-Z0-9_.-]+$" maxlen="31" help-string="alphanumeric value">
         <validate uniquein="#users/entry/@name"/>
       </attr-req>
       <element name="phash" type="string" maxlen="63" optional="yes"/>
    </sequence>
  </array>
</sequence>

每次部署上線的流程如下:

雲端資料庫更新 (驅動)-> 防火牆機器schema更新 ->(客戶手動 可不更新)網站portal更新升級新版 ->Web UI 響應客戶安裝之版本

如上所述,我們的目標是要建立一個隨著schema響應的UI,所以和一般網站開發的邏輯稍微不同,市面上當然也沒有類似的框架可以拿來使用;當然我們也盡量避免自己造輪子,所以舊版的網站我們用Ext.js(如果有人聽過的話…)作為基底,新版網站我們用React.js做為基底,在此基底上自建我們的框架。

而資料流方面,由於公司客戶的使用人數都在極高的規格下,在整體網站效能上也需要特別留意,我們使用了Rx.js,此框架可以取消已發送的Ajax,此功能對於減少API loading幫助相當大,非常推薦給大型網站的開發者使用,一旦完全理解它能提供的功能與用途,大概就回不去了。

資料流:

DB data -> Global Redux store (dispatch action to make ajax call in rxjs to update state)-> local context component level data -> local fields data

UI:

Own UI library includes:

Widgets -> Builders -> Viewers

React router for routes -> page, component with schema and customized fields plus business logic -> import UI from own library to render

由於UI都是延伸自內部開發的library,所以整體的視覺表現也相同沒有問題,而關於全公司共用的元件像是header, sidebar之類的UI元件則是有microservices architecture 概念在裡頭,統一有別的部門開發而我們就像是安裝一個npm package一樣,按照文件檔撰寫程式。

架構大概敘述完成,非相關領域的應該很難咀嚼其中的硬道理,不過原則上就是記載一下新的學習。

希望年年都能新的學習,持續進步,COVID-19病毒早點結束。

分類
About Mike

Web軟體工程師的階段感想

如果說當一個軟體工程師也有分階段(見山是山、見山不是山、見山又是山),那我想現在的我一定是在‘見山不是山‘的階段,寫下現在的想法,希望自己幾年後再來看,可以邁入見山又是山的階段。

網站的技術發展從Web2.0的年代到後來智慧型手機普及後RWD網站變成標配的現在,發展上不管是前端或是後端都經歷了很大的轉變,對我來說前後端是緊密不可分的;雖然常有人說沒有真正的full stack,不過我認為一個full stack並不是要同時專精於前後端,而是能夠知道前後端所需要處理的事項,如此一來不管工作是做前端還是後端,都可以知道另一邊的工作是什麼、雙方應該怎麼配合寫起來才順暢。

以往桌機 1024 x 768 的年代,多數的HTML都是使用<table>來完成,每個網站看起來標標準準整整齊齊,頁首、內容、頁尾排列方式大都相同,當時的設計,簡單的css樣式就能滿足,網站頁數通常也不多,常看到將css寫在頁面上的(in page style),並不是奇怪或者是很難維護的事。

網站應用程式開始發展後,開始出現了百萬人數訪問的網站(電子商務、售票網、大型論壇),這時候後端工程師常需要同時處理資料庫(現常稱為DB ENGINEER)以及伺服器(現常稱為DevOps),後端工程師的薪水往往大幅超越前端工程師。如何讓網站推不倒是當時主要的客題。

伺服器穩定後開始發展起了後端程式碼維護的相關模式,各種MVC design pattern陸續問世,Python Django, Ruby on Rails, PHP Symphony, Yii, CodeIgniter等framework 開始讓工程師互相合作整合程式碼,前端工程師專注在View and Controller(多數狀況只需要知道Controller吐出什麼資料),後端工程師專注在Model and Controller。

第一支智慧型手機問世後,網站開始要能在手機上瀏覽,開始了RWD( responsive web design )前端網頁開發的年代,大家開始用media query讓網頁可以自適應各種瀏覽器尺寸,從手機、平板、筆電、桌機都要能瀏覽,<table>這種本身非responsive的元件,反而變成能少用就少用。這時候出現了很多前端的切版框架:bootstrap, foundation, pure等css framework 幫助前端工程師能夠快速的切出一個RWD網站版型。

React Vue Angular

接下來進入了前端開發者的戰國時代,因應著JavaScript的廣泛使用,各種前端的框架開始出現,從最早的ember, backbone, angular, react一直到最近的vue ,每個框架主要目的都有些不同,但通常出發點都是能夠透過SPA( single page application )去減少伺服器的負載同時也減少前端的負載:簡單說,使用者換頁時不再需要重新發出請求到伺服器等待回傳一個新的頁面,而只要請求需要更新的資料然後更新頁面,減少了伺服器吐出的資料大小,也加速了使用者看到網頁變化的時間。

不過(轉折點來了)事情沒辦法就是這麼單純,SPA的缺點就是網頁只有一個頁面網址,即便透過一些前端router來操作網址,許多重要的meta資訊,網路爬蟲爬不到,甚至頁數不夠沒有結構化的頁面內容,如此一來網站的SEO排名就不容易上升,所以開發者們又開始專注以前沒有前端框架時不會處理到的問題,用SPA並且使用SSR( server side rendering )讓網站的SEO可以比較好。

打了這麼多,想說的是現在許多公司或者是開發者開始一窩蜂熱使用框架去開發網站往往是讓我最難理解的事情,事實上,多數的網站都是非高流量非高效能的一般網站應用程式,若是很單純的使用後端MVC不僅可以搞定基本前後端架構同時SEO也可以輕鬆達成,未必需要變成是一定要後端API搭配前端框架。

每種框架都有他的優缺點,如何判斷並且了解網站需要使用什麼樣的架構是每個資深工程師很重要的課題,技術的發展是用來解決問題,但近年來的開發者的選擇真的常常讓我不解;(舉例來說,一個只有一頁有預約功能網站也要做前後端分離然後導入React Js。) 如此一來,開發上往往為了達成某件事而要多做很多事,除了檯面上那幾個大型流量或者是特殊功能需要的網站之外,其他網站的架構真的需要這樣嗎?

回頭呼應首段,上面描述的多數是我個人心得,也簡單解釋了為什麼我認為我處於”見山不是山”的階段,這未必是個好比喻,但總覺得開發者在技術的發展以及選擇上只是在繞圈圈(SSR -> SPA -> SSR),希望這篇文章提醒自己在幫別人分析網站時可以跳脫出最火紅的框架去思考什麼是最好的建議,同時也希望幾年後回顧,我可以有重新的”見山又是山”的新領悟。

分類
About Mike Startup

The journey of TIXINN(易票亭)

兩年時間很快的過去了,一年多前的我與我的夥伴決定將易票亭改版正式踏入台灣C2C售票的市場,一年多後的現在我們也正式的退出台灣C2C售票市場。

From 0 to 1

2014是創業的第一年,那時沒有題目,先接專案保持收入,那年有一件大事:江蕙宣佈封麥!起初只是想買個兩張孝親票,卻怎麼也沒想到後來一頭栽進售票的市場。

記得啟售那天,走了附近幾間超商,排到馬路上的人龍讓我立刻意識到要排到隊甚至買到票應該除非湯姆克魯斯出馬,不然真的是不可能的任務,於是便轉而向網絡上搜尋…

接下來可預期的就是尋票過程中遇上所謂的黃牛票,其實黃牛票也沒什麼特別的,畢竟就是個你情我願的交易,價格可以接受你就買,黃牛們覺得自己就是一位商人,哪個商人不是用成本加上他的利潤然後再將商品賣出的呢?但如果你實際去找票的話會發現,在美國有像STUBHUB的中間人做第三方把關,在台灣只能嘶嘶嘶(私訊),對就是像蛇一樣跟每一個黃牛私訊問價,先不提價格,光是要花上的時間就是好幾倍。

那來解決這個問題吧

為了減低找票所需要的時間,我們想打造一個平台,讓賣家可以快速地將想出售的門票上架並且清楚的標示價格(可高於原價),這樣一來需要找票的買家就可以快速地在平台上找到他要的門票進而聯繫賣家完成購票。

TIXINN初版 票券分類頁面

門票資訊頁 2015 Aug

準備開始推廣網站的同時,很幸運地也入選了AppWorks加速器#11,扎實的每天都想著如何做到我們所設定的PMF(product market fit),每天絞盡腦汁的問自己、問使用者、問賣家十萬個為什麼。

透過一次一次的會議釐清方向

在加速器的過程中非常感謝所有給過意見以及指導的前輩,像是關鍵評論網的Mario就提供了我們非常受用的經驗分享,時間像光速一樣三個月飛過,也參加了demo day正式體驗在千人面前pitch的場面。

Appworks demo day #11

然而加速器的結束不是結束,對易票亭來說反而是全新的開始:這三個多月的過程中我們會談了真實的買家與售票的黃牛,我們也去過小巨蛋幾趟發傳單、看現場狀況、理解現場售票的黃牛阿姨伯伯到底在做什麼;商業上,我們也知道再不把商業模式帶出來團隊就要吃土了(對所以中途也經歷了夥伴撐不住先離開);用戶成長上,雖然有幾次活動(HBL冠軍賽、職棒總冠軍、天王天后演唱會)讓上線人數有不錯的成績,但都僅僅限於一個peak一個peak,沒有達到一個很穩定的量

知道了這麼多可以改進的地方,我們決議在2016的一月進行改版二月上線,讓網站不再只是個找票的平台,正式踏入售票的行列。

那就來售票吧!

手機版售票介面 1手機版售票介面 2手機版售票介面 3

我們設計的活動頁面UI flow,找到場次 -> 觀看座位圖 -> 選擇票價前往付款

桌機版售票介面

TIXINN style guide

成立了公司,有了商業模式,接下來就要起飛啦!!! 錯!事情哪有你想得這麼簡單。

上線前期和大多數的C2C模式網站一樣,由於門票是需要由持有門票的賣家來上架的,沒有票就等於沒有商品,沒有商品就不會有買家來下單交易,沒有交易賣家也不會想來賣;標準的雞生蛋蛋生雞場景,於是我們決定先讓網站上有商品。

認識黃牛

講到黃牛大概就要先提台灣售票市場上被法律規範到變形的機制,為了保護消費者,文化部票券的定型化契約載明了,最晚十天前可以退票,且退票不能收取超過10%的手續費;看起來沒什麼問題的契約,但也等於是為黃牛開了一個缺口,簡單說,我先搶票,搶完來加價賣賣看,賣不完我就十天前退回給主辦單位承受10%的損失,對你沒看錯,就是只要10% 。

這對視自己為票券商人黃牛來說,根本是比周子瑜笑容還甜美的商品呀,成本只要定價10%,熱門一點的票翻倍賣還可以賣得掉,如果是你有能力搶到很多票的話,你不搶嗎?

但實際經營後其實可以了解到黃牛們比起詐騙實在是溫馨到不行的一個族群,如果你理解他,粉絲還可以跟他多多少少殺殺價,反正牛伯伯們買票是為了賺錢,願意買你就買,他們從不會逼你買;但詐騙不是,是一直騙你有票,然後要你匯款,匯完款就封鎖謝謝再聯絡,報案多數狀況下款項也追討不回來,每每看到粉絲遇上這樣的遭遇,就更深信易票亭存在之必要。

所以多數的時候其實沒有所謂的黃牛集團,很多牛牛都是個體的散戶,有主業當工程師的、有開文具店的、有家裡是小開的、也有就是專門買賣各種有價值物品謀生的。不過有時候會發生某個人的賣家要找的票別人才有,就會再產生加價賣的狀況,等於是A賣家賺,B賣家也還是賺,反正有賺他們就賣。

培養黃牛對平台的信任感後,票漸漸增加。過程中我們也常反思,這樣的平台究竟是利於黃牛還是不利,答案我想大概是參半,因為價格一旦透明化,買家可比價不再需要私訊後,牛牛的獲利勢必會受到影響;但反觀,可以躲在平台背後交易,不再需要躲警察偽裝成顧客抓人(抓到也只能罰錢,這條社維法裡無刑責案底),也許就是種得利了。

廣告

商品有了之後,再來的工作就是替商品找到買家,找到買家有很多種方式,首先我們嘗試的就是廣告。

廣告主要的負責人不是我,是我的夥伴Renee,經過前期不斷不斷地嘗試後,終於在小幸運女神演唱會前試出了結果:

臉書廣告成效

經營臉書社團

我們也實際的經營了臉書的換票社團,讓自有的幾個帳號,可以在上面免費的張貼網站連結,同時帶來免費的流量。

初期社團人數少,成效也不好,但經營社團有趣的是,差不多1000人是一個門檻,當你突破1000人後,一下就到3000人,然後不知不覺又到了5000, 10000人,也就是說,今天一個歌迷買不到票要到臉書找票時,歌迷很有可能又進入了我們的流量入口,是個非常值得投資的項目。

SEO

SEO是流量成長必要執行的項目,雖然改變往往需要時間才會反映在排名上,但免費且穩定的帶來自然搜尋流量,是每個網站主都必須要經營的功課之一。

SEO執行有很多招式,事實上我並沒有用什麼特殊技巧,就是把Google官方提到的要點是項針對我想要做的關鍵字(藝人名字+演唱會+售票)去設計,三個月後在我們針對的重點演唱會收到了成效:

TIXINN SEO performance No.1

從二手到一手

上面幾個步驟完成後,每個月的營收都有了顯著成長,接下來還需要隨著時間以及行銷資源的投入,讓越來越多人知道買不到票可以到這裡來,營收就會持續的成長。

一個二手售票還是一個完整的售票平台,雖然架構上沒有嘗試挑戰大型演唱會搶票的情境,但賣賣小型場次還是可以很穩定的完成交易。所以我們也和幾個主辦單位談合作,協助共同、獨家賣了一手門票,其中有藝文表演也有演唱會,最特別是當你小時候天天聽歌的歌手分享你的連結時,真的是有一種難以言喻的感動阿!

黃大煒轉貼易票亭售票資訊

就這樣從2016年二月每月營業額10萬元,一路到十二月營業額來到將近200萬,至於後來為什麼沒有了易票亭變成了現在的go票亮,我與夥伴也於今年初正式的將易票亭資訊股份有限公司清算關閉,則又是另一個故事,不過基於種種理由就不在這裡贅述了。主要仍是因為台灣市場小,有了這樣的經驗後,應該重新的將眼光放遠,挑戰更大一點的題目。

還有好多還沒做的事

其實還有好多好多我們想嘗試在易票亭上的商業模式我們還沒嘗試:

想過推信封袋上的廣告,因為每一筆門票買賣的交易,門票都會經由我們查核無誤後再用易票亭的信封袋寄出。

想過將二手市場上的數據提供給買家參考,讓買家可以清楚地知道,既然要買二手門票,什麼時候是買賣的低點,最適合入手。

五月天二手門票漲跌分析

想過協助門票一直賣不好的藝文產業解決問題,不管是降價賣,或者是像國外的訂閱制讓觀眾可以付一筆年費及可無限次數的觀看藝文場次。

想過和其他即時訂房的服務合作,讓前來觀看演唱會的粉絲可以一條龍的同時完成訂房。

想過透過機器人即可在對話視窗裡完成購票,加速消費者完成購票所需的時間。

想過成為售票公司台灣場次中國售票的灘頭堡,讓中國粉絲要前來台灣看演唱會的可以在中國境內即完成交易,不需要到台灣的網站來交易。

後記

不知不覺整理完了這篇文章,回想起這兩年不長不短的過程,非常感謝一路走來的夥伴,給予我們指導的所有前輩、朋友,讓我們學習到非常寶貴的經驗。

現在不會再有媒體朋友假日打來問演唱會搶票的亂象可不可以採訪,不會有朋友私訊來求各大偶像的門票,但台灣還是有一間二手售票公司存在,讓一部份的二手交易是留在台灣,而不是境外交易全部被國外業者賺走,夥伴們也有比創業前更好的生活,也算是有完成當初的初衷。

這篇文章從年初寫到年尾,也終於趁著生日好好的把它寫下來,讓下次需要一些養分的時候可以回顧。

那接下來?

還是讓我先把專案公司欠了一屁股的案子還完,休息一下,拿著這從零到無過程中的經驗再出發吧!

分類
About Mike

Hello world!

Welcome to my personal blog. I will start writing some articles here!

Testing article API connection.  Cheers!