NodeJs In Action 聊天室範例 (使用Socket.io with v1.4.5)

最近想深化對 NodeJS 的基本認知,參考一本 NodeJS In Action 的書,當中有一個聊天室範例應用到 Socket 。依據範例做當然錯不了,但範例使用的 Socket.io 版本是舊版本  (0.9.6),當昇級至 1.x (比如1.4.5),運行時便有林林種種的問題。

因此我以範例作根本,以 Socket.io 1.4.5 的方法編寫了能運行的 Example:

https://github.com/gordonchanhk/NodeJsInActionChatRoomExample

nodejs-in-action-chatroom

Getting Laravel (5.2) works with Heroku for Shopify Embedded App Development

Inspired by REVENUE AFTER 3 YEARS IN THE SHOPIFY APP STORE, I start exploring the world of Shopify App Development using my favorite PHP Framework: Laravel and hosts it on Heroku. I don’t have solid idea what App I am going to code, the work that I am going to share is how I finally get Laravel basically work inside Shopify as Embed app and get it running on Heroku.

I assume you have basic understanding what is Heroku / Laravel / Shopify Embedded App (EASDK).

Continue reading Getting Laravel (5.2) works with Heroku for Shopify Embedded App Development

Shopify Expert - 找他們合作的理由

利申:我是 Shopify Expert 的一員

Shopify 作為 SaaS 服務供應商的表表者,其申請以至運作方法皆以簡單快捷為主,所以有志利用它開站的人在一般開店的過程中一般都沒什麼困難。自己一手一腳開的店亦更能讓店主全程體會箇中的血與汗。這麼一說, Shopify 所提供的 Shopify Expert 「工種」卻顯得有點無謂,因為既然開站的工作基本能一手包辦,還有什麼難的東西非 Shopify Expert  協助不可?

作為 Shopify Expert 的一員,我很認同以上講法,更敬佩為己站一手包辦一切的他們。Shopify Expert 的存在,其服務對象並非他們,而是為一些需要在技術上、運作統籌上、以至日後後續運作、平台優化的層面上的提供協助的 Shopify 用家。

Shopify 提供了最基本的網店運作平台。然而其背後其實包含很多進階的功能,或要進行較深入的功能開發時,便需要一些對 Shopify 有較深了解的人提供協助。以下一些案例作為參考:

- 多語言功能開發

Shopify 其官方預設語言為英語,但提供了翻譯功能。然而這僅代表你的網站在某一當下只能有單一語言。要達至多語言功能,即是要讓網站同時做到中英語言選擇,若沒有特別編程下,你只能申請兩個網店來運作。 作為 Shopify Expert,我們則會利用適用的 Shopify App ,如 Langify 讓網站達至多語言功能。當然這不單單只是「安裝App」就足夠。在整個與 Langify 的 Integration 中,會預到許多 Langify 自身不直接支援的功能。Shopify Expert 需要理解 App 的運作原理,有時更要與 App 的開發人員溝通以理解如何應對某些開發協調問題。

-產品款式設定

Shopify 提供產品款式設定。即是說一件商品,你可以設定其可供選擇的樣式、如顏色、尺寸大小、度數。單一商品若只有一項樣式選擇問題倒不大,但若是單一商品有多於一項樣式選擇,其設定難度便會大增。比如某一商品有三顏色和四大小可選擇,其總商品共有4 x 3 = 12 項商品細明需要處理,每商品細明要有其對應的 SKU、存量設定。我曾預上一產品有十款顏色、左眼20項選擇,右眼20項選擇,依 Shopify 的設定法,我需要選定10 x 20 x 20 = 4000 項細目,這是人根本不能勝任的設定工作。作為 Shopify Expert 我們的職責是面對開店時預到的客戶要求,要考慮客戶的要求如何與 Shopify 的運作法則相磨合,來得出兩者兼容的開發方案。

- 更長的試用期限

一般 Shopify 申請能讓你得到 14 天的免費試用。而作為 Shopify Expert  我們能夠開設無限試用的網店。你可以透過他們開設網店獲得更長的試用期。他們的無限試用期主要是配合他們開發網站需要長時間調設網站之故,而你若確定日後付費開店,他們會獲得分成。所以這益人利己的事實在值得參考。

不同的 Shopify Expert 所提供的服務與收費、項目管理的方法和起貨/開發期可以有很大的差異。國外與本地的服務形式也會不同。說到底不同開發者的性格各有不同,貨比三家是一般的常識吧!

希望這文章讓你對我們 Shopify Expert 有更多認識。

Naturali Japan – 美曈 Shopify Store

naturali-japan-shopify-site-responsive-displays

Naturali Japan 是近來參與的 Shopify Store 開發。當中包括的挑戰:

  1. 與日本人合作
  2. 由開發至發佈為期一個月
  3. 讓網站能以 3 款語言和 3 種貨幣運作

當中最具挑戰性是讓網站能以 3 款語言運作。Shopify 基本功能支援翻譯功能,但只能於一網站上使用其中一款語言。要讓網站能支援多項語言,則需要使用其他 Shopify App 。客戶選用了 Langify ,所以我主要的工作是讓站台與 Langify 整合。

在整合過程中,遇上 Langify 與其他 App 的支援問題,比如客戶也選用了 Product Customizer 來處理商品的屬性。縱使 Product Customizer 的支援網站提及曾得到 Product Customizer 的回應說能相互兼容,但在與兩方一連串的電郵查詢後,得出的回應是他們基本不能互相兼容。Product Customizer 雖表示他們正部處更新版並可望令其功能與其他 App 更相容,只是未有公開期限。雖然這樣,作為 Shopify Expert 的價值就是利用對 Shopify 編程的熟悉來為客戶解決問題,最終還是能利用一些略為轉折的方法得出了解決方案。

此方案我也利用了 Taiga.io 作為與客人溝通問題、改良要求的 PM 工具。它容許使用者建立客戶戶口、定義 Ticket 類別、狀態。美中不足是沒有附件功能,但經已方便和客戶的基本溝通。

Shopify 收費不平宜但你還是可能選擇它的原因

上篇談及「利用 Shopify 架設網路商店的例子」,這一篇嘗試進一步協助剖析 Shopify 是否真正適合你。

shopify-google-search-onlineshop-result

雖然網路上伸手即有的一大堆網上服務平台可選,隨手一找這些也是你可能有興趣而又與 Shopify 相類似的網店平台:

  1. storenvy.com
  2. shopline.hk
  3. shopio.com
  4. volusion.com
  5. bindopos.com‎

基本上是即申請即可開店,又或是風格相近而又有名氣。

付費㗎喎!又唔係平

要找平宜的實在有許多選擇。這些平台的服務收費有分一次性成立費、月費、按交易收費、功能附加費等等。有些平台開店成本低至 HKD$500,月費HKD$50。(Shopify Basic Plan 要 USD $29 (~HKD$230) 另加交易手續費。)然而 Shopify 在這方面並不是平價網店服務平台。在商言商,一個服務供應商要有合理的收費才能支持其持續營運。有營利才能驅使平台有更穩健的發展。所以要是選擇的話, Shopify 不會是你的選擇。只因 Shopify 不是最貴的那一家,但要比它平宜的大有人在。

自主程度與開發者協作

那麼 Shopify 為何在云云選擇中被我看中?我被 Shopify 吸引的是其提供的自主度比其他平台優勝。它除了提供不同 Theme / Template 來讓技術能力較缺乏的用家選擇外,其自家的 Theme Configuration Tool 讓建立 Template 的製作者定義一些基本設定,讓其他不善編寫網頁的用家也能有自定義的空間。 除此之外,Shopify 自家的 Theme Editor 編輯工具再其自定義的功能之上,提供以 Liquid 這項 Template Language 讓開發者進行更進階的編程來製作更多樣化功能的網店。若果 Shopify 用戶想達到較複雜的網店設計而又沒有現成的 Theme / Template可選擇,有這類 Template Language 再找懂這項編程語言的網頁開發者協助便能達到他們的目的。Shopify 對開發者亦有很豐富的支援。除了完善的支援文件外,收益分成也是驅使 Shopify 開發者更積極協助其商家優化他們的網店,網店生意更好,他們所得的分成也會更多。

所以(利申),作為 Shopify 開發者 ,如果我為更多人建立 Shopify 網店,而他們的業務不斷發展收益增加,我也會漸漸有更多的分成收益。亦因為這種分成制度,讓 Shopify 開發者對 Shopify 有更多交流,以獲得更多支援、改進,讓他們為其客戶達到更多設計/功能目的。而 Shopify 開發者也務求與其客戶建立良好關係去優化他們的業務。換句話說,找一個 Shopify 開發者去開設網站能讓你的網店發展事半功倍。

歡迎你對 ShopifyShopify 的開發者協作計劃提出疑問以了解更多。

利用 Shopify 架設網路商店的例子

Shopify 是甚麼不會是你閱讀這文章的目的,云云網際上不難找到深入介紹 Shopify 的文章。我只想嘗試介紹一些利用 Shopify 做後台的網站,讓大家了解更多 Shopify 如何協助他們「站」起來。

Somethin’ Sweet

somethin-sweet

我是從 Facebook Suggest Post 接觸這個 Somethin’ Sweet 網站。一張張誘人的相片,的確俘擄了不少眼球。基本上這個網站規模拍不住 YesStyle.com ,主打韓風的購物網站。它善用 Shopify 的 Collection 設定,把林林種種的商品歸類一起。既分種類,亦以模特作分類:

分類 / Categories: http://www.sthsweet.com/collections/bottom/skirts
主題 / Theme: http://www.sthsweet.com/collections/going-out
模特 / Models: http://www.sthsweet.com/collections/fiona

somethin-sweet-fiona基本上 Somethin’ Sweet 充份利用 Shopify 的基本功能,並毫不吝嗇發揮 Cross-sell 法力,在網站中不同地方提供 Cross-selling sections。基本上每件商品文末會放,在購物車頁尾又放。林林種種的 Cross-sell 務求讓你不斷加、加、加東西入購物車中。

 

me Me & ME

me-me-and-me

這個 me Me & ME 網站相對細小,介紹它乃網主是黃占女兒黃宇詩一手創辦的內衣及睡衣的品牌。黃宇詩出身娛樂世家,人脈廣要開店有何難。但她選擇利用 Shopify 作為其網店平台(加一間位於中環半山 SOHO 區附近的 PMQ 元創坊的實店),確作為其可靠的參考。當然,黃宇詩善做主持不等於她能駕駁編程,她是透過 Chic Workshop 替供開發技術。Shopify 的過人之處是它除提供建全的購物功能外,它還有一套自由度高的主題模組開發功能。其主題模組語言 Liquid 讓網站設計師相對輕易將設計與功能配合起來建構網站。比起由零開始用純 HTML / PHP 開發網站省下不少功夫。

 

K11 Design Store

k11-design-store這是我朋友 Benny Wai 為 K11 利用 Shopify 開發的網店。當然,這網站不單單用網店功能,其於它偏向於 Campaign / Event 這範疇,網站大部份內容乃非商品內容。Shopify 讓你開始不同分頁,URLs 是 SEO Friendly,有利於宣傳。這網站的 Blogs 分頁利用了 FaceBook Embed Post 來達致將 Facebook 內容隔入網站中。

 

Shopify 表面上帶給你建構網上商店的好處,微細點包括穩定的系統上線率,Web Hosting,自定網址、其最值錢的莫過於他們採用 CDN 服務 (Fastly),有效為網站加速內容下載。這是一般單單申請網域和網上空間服務沒有提供的服務。

當然一講到要錢的服務,會把許多「有心創業」的人嚇退。其實網路上免費午餐那個年代經己過去。現在只要你付出合理的價錢,其實你經己可以獲得相應優質的服務。該等付費是支持服務提供者繼續去提供服務下去。

shopify-price US $29 -> HKD $230 一個月,己減省電子商貿方面的開支。基本真正要付錢的地方其實是找開發員幫助你粉飾網站,讓他們向你提供技術,把你的網站看起來較 On Brand ,符合品牌型像。

而小弟也是 Shopify 的開發者之一,KEA 是我的其中一個利用 Shopify 的Portfolio 。

kea

稱不上大師,更不及上述兩位 Shopify 開發員。但若然利用 Shopify 開網店有疑問的,不況聯絡聯絡看看可以為你解答疑問。

GoDaddy with good price but extreme poor support

The web hosting I am using is ICDSoft, but from time to time I will help people setting up website using other web hosting base on their requirement and the budget they can afford.

ICDSoft is very famous in her stable services as well as their extreme helpful support (Suresupport). And I never find them so helpful once I started using some other web hosting, namely, GoDaddy and Hostgator.

Hostgator comes to my eye-sight because of they open China market when I search for economic China web hosting. It does not cost much, but their admin panel is quite messy, and their support is also not fast enough in catering my inquiry. However, it is much better than GoDaddy.

GoDaddy is very famous in their domain sale, she often provides very cheap domain sale. But it also famous in their un-user-friendly admin panel, complicated control of your account. You are not only fail in using username to login your admin panel (you have to use the customer ID). And recently when I help my friend setup the Delux web hosting plan, it almost turns me crazy during the email setup. Therefore I seek for their online support.

After looking up the whole website, GoDaddy only provide Live chat or call-in support. There is no email support or online support ticket system for firing support ticket. I turn out opening the Live chat window and see the screen:

Screen Shot 2014-06-04 at 上午12.45.44

Screen Shot 2014-06-04 at 上午12.45.32

It turns out I waited an hour for a support expert to chat with me. And before I reach the expert, I already sort out the issue by surfing from the Internet.

To know that, support@godaddy.com no longer work:

Screen Shot 2014-06-04 at 上午12.46.14And this is really poor to me, as I often wish to share screen or text file for resolving issue, and GoDaddy turns me down really deeply.

Well, my friends look for economic approach, I can only try harder to help them by myself.

A rough start of Google Tag Manager

I assume you have a rough idea what Google Tag Manager (GTM) is, if not, you may either read its official website, or watch the nice Introduction Video to get the brief idea.

Once you have a brief idea of it, it sounds like ‘Yeah! That is our choice and we need it to empower our marketing / site tracking strength and management.’ by marketer, or ‘Gosh! We have to implement it in order to off-load the work of various tag setup from IT Team to Marketing Team’ by I.T. Tech. I am a front-end web developer and often need to make suggestion / decision to confirm whether to go for an approach, and Google’s product often a nice choice to have, but probably not this time when I am writing this blog.

Somewhere over the WWW have people like blogger / SEO expert introducing GTM by coping / elaborating its good point (mostly the good points that mentioned by Google Tag Manager official website). But when you come to the analysis phase, you will find it lack of detail documentation to implement it when you need it a bit more advance.

My case is to start preparing the migration of Google Analytic (ga,js) to Google Universal Analytics (analytics.js) for my company’s E-Store, and I have no difficulty to setup the Containers, Tags, Firing Rules, Marcos for general site tracking using Google Universal Analytics tracking type. I can see the configuration I did in GTM start populating data to various report, mostly similar with what I can see in existing Google Analytics profile. However, for some case we need to have different tracking code with different value per several different page, then the problem I face is the grow of Firing rule. And the worse thing is, all the rules / tag are listed linear, without folder structure for organization.

Furthermore, leverage the tracking code deployment task from IT team to marketing team is not an ideal way in terms of site stability. If there is bug in tracking code and is being deployed without proper testing, the site will subject to the issue and the IT department often be the party who being blaming by site user instead of the marketing team.

I would advise IT team to implement Google Tag Manager to their website, and use it as a way to simplify their tracking code deployment, and keeping the account secret from non-IT team member, so as to avoid them from introducing issue to the site.

iOS6 與 Web Developer 的關係

自 21 SEP iOS6 釋出後,過了24小時左右,花了一小時自動更新,把手機轉到 iOS6 去。更新的原因,主要是因為它對 Safari 進行了若干改進。

在左圖你可以見到,Safari 的若干改進中,有前所未見的更新:支援照片上傳 (Support upload from media library) 。此前,因為 sandbox 原故,或是因為沒有做好 portal,手機隨了靠 native app 如 PhoneGap 來作搭橋方式,把資料送上去後台程式。現在連網頁都能夠上載相簿中的相片,甚至即是拍照,這可是一個不顯眼的突破。對於一般上網族,未必留意到這個改變,但對於網頁開發人仕,可不要忽略這個新功能。因為,這個新功能帶來的方便,可改寫你之前對某些認為一定要寫 native app 才做到的事情,變由拍一張照傳到後台,經後台分析而得出處理結果。

此外,對網頁開發員的另一個好消息(突破相對較小),是其 JavaScript 的執行效能。且看以下網站將 iOS5 跟 iOS6 進行的對比測試:
http://www.newmobilelife.com/2012/09/15/ios6-vs-ios5-safari-benchmark/

可看到網頁呈現的反應之差異。實際前往我公司的網上商店,可感受到網頁很快便能完整呈現。

當然,新 Safari 也同時帶來一些問題,就是對 POST Ajax 的 caching 處理跟 iOS5 。因而有些網站反映有一些問題出現。解決方法是添加一個不斷隨時間而變的數值到 ajax 作出回應的 function call 中: http://stackoverflow.com/questions/12506897/is-ios6-safari-caching-ajax-results

至於其他改進,也是使用層面中體驗經歷,也不用作深究了。

Facebook app – 由 HTML5 回到 原生 iOS app

Facebook 曾打響旗號,將其 iPhone app 和 android app 改為以 app container 配合 HTML5 來製成適合智能手機上使用的 mobile web app,一時將 HTML5 的風吹得熾熱,讓人們覺得 HTML5 web-based apps (a.k.a HTML5 app)正是手機程式開發的理想方向之一。然而近來又似乎在打退堂鼓…… Continue reading Facebook app – 由 HTML5 回到 原生 iOS app