跳到主要內容

文章

目前顯示的是 一月, 2016的文章

正式產品開發,技術框架的選擇

每次面對新的專案開始,對於開發者來說總是充滿了許多驚喜及幻象,總是幻想著該如何使用最新的架構在開發流程上,將這次的新開發專案,視為是一次的挑戰,一個可以讓開發者試刀的競技場。

對於技術的熱情及憧憬,總是無法避免,技術本位的我們,心中總是充滿了熱情及想法,看到許多好的框架,酷炫的套件庫總是會希望來上一回,但是火砲洋槍一開始使用時搞不清楚,不僅傷身,還會搞的自己灰頭土臉,更不用說實際上要用在動手殺敵上。
火砲洋槍,中華武術,那個好? 每次看到許多火力展示,洋槍大砲的面前展示,偶而來個酷炫的『成果展示』,總是讓我們底下看的目眩神迷,長官們看的拍手叫好,就只差一個起立敬禮。



但是對於實際要開發產品,這些 F-999, 阿趴器等新世代的武器到底是不適合我們? 這到底要怎麼評估!?
火砲洋槍炫技拆解 在激情過後,目眩神迷之後,我們關起門來,靜下心,重新旁敲側擊一下到底這火砲是怎麼跑得,這洋槍會不會傷身,畢竟中華武術五千多年,都是先講求不傷身在追求成效,否則頭緒沒有釐清,就成了七傷拳,傷人七分,傷己三分,這就不妙了。

炫技之餘,總是會有跡可尋,從開源專案來看,我們可以從大多數的 Readme 略知一二,到底這到底是什麼咚咚,以 react 我們就可以從開宗明義瞭解,

A JAVASCRIPT LIBRARY FOR BUILDING USER INTERFACES
以及底下的段落可以略知, react 並不是一個框架來著,而是稱呼為 library ,同時也能夠和目前的專案整合使用,採用了所謂的 VIRTUAL DOM, one-way data flow 的概念。

當我們有了一些瞭解,也開始抓到一些 神秘的字眼。
解開神秘的面紗 當抓到某些字眼,以及神秘的詞語時,再度將這些字串前往求尋 google, wiki 大神的幫助,讓我們再接下來閱讀文件時,這名詞的定義是什麼。

這時就可以瞭解,這洋槍到底是一把小手槍,還是一把火箭筒來著,至少定義上我們可以明確,也比較能夠瞭解,對於專案的導入是否適用。
文件及測試 我們可以視為前面的動作稱為『快速導覽』,接下來就是是否要採用套件的關鍵,從裡面文件是否充足,有哪些實際案例,範例展示。

如果是一個開源專案,從技術性上可以
test code 是否充足,能否執行google , stackoverflow 是否有許多人討論github 程式開發進度狀…

facebook request not return email when using passport-facebook

facebook request not return email when using passport-facebook

自從 facebook api 改為 2.4 版本之後,項目就變的越來越多,變化越來越大。
對於 node.js 開發者來說,大部分開發者使用 login 或者帳號驗證機制大多會採用 passport.js 進行驗證。

因應到 facebook 2.4 以後的版本,特別要設定欄位的回傳,才會收到 email 的設定。
在一般使用下,如果沒有要取道額外授權,大部分都是直接使用 passport + facebook-passport 直接按照 demo 就可以設定完成。

但是如果像是要多要求一個 email 的話,而且不幸你得 facebook app 又是最近才開始建立的,勢必就只能使用 2.4 || 2.5 的版本。

就會發生取不到 email 的狀況,解法其實 facebook-passport 有提到怎麼進行。說明連結

The Facebook profile is very rich, and may contain a lot of information. The strategy can be configured with a profileFields parameter which specifies a list of fields (named by Portable Contacts convention) your application needs. For example, to fetch only user's facebook ID, name, and picture, configure strategy like this.
意思指,如果你需要特殊權限,或者指定某些特別欄位的話,請必須要加入 profileFields ,設定需要的欄位(當沒有特別設定就會略過)
解法 在使用 passport 的時候,設定方法就需要設定類似如下

passport.use(new FacebookStrategy({ clientID: config.facebook.clientID, clientSecret: config.facebook.clientSecret, …

網站開發是怎麼一回事!?點解!?

網站開發是怎麼一回事!?點解!?
此篇文章獻給完全不瞭解網站開發是何物的人!

網站開發,聽起來就是一個神秘又奇妙的名詞,這類的人,總會讓人覺得講著神秘的語言,笑著奇異的笑點,當群聚的時候有一個很強大的力場。

這群人,就是大家口中所說的『程式設計師,網站工程師』

身為專業的人,口中烙英文這也是很正常的事情,就如小弟本身,每天都至少掛著很特別的名詞 - HTML ,念起來潮到一個不行,更不用說 CSS 什麼的,那就太夢幻了。

網站開發,在其中工作的人,不論是設計,開發,到 QA ,一定都會讓其他人覺得,你電腦一定很好吧,然後就把電腦送到你家門口,請你幫忙『看一下』。

這種事情一直都在我們身邊發生,但是這邊要極力聲明『電腦問題,請找專業』,請認明黃色 X 屋。
網站架構什麼的 對於各位來說,網站就如同信仰一般,深植於你我的心裡,隨時在身邊發生。舉例 facebook, google, line 無一不用到網站,所以這玩意兒,已經是生活中不可獲缺的一部份。

那網站的架構是什麼?那就先切分成兩個大方向來看,網站的表皮,網站的肉。
網站的皮 -> 網站資料 簡單來說眼睛所看,就是網站的皮。送出的資料及回饋資訊,就是網站的肉,也就是網站資料。(至於資料是怎麼儲存,怎麼進行!?這就不屬於本文所介紹的範圍)

所以網站架構就是這麼簡單,但是卻需要至少一批人來進行。 從專案需求者,專案架構師,專案管理師,設計師,前端設計師,後端設計師等人都會需要,當然一個開發團隊不一定會有這麼多人,但是這些角色是一定都會存在著(有些人重複身兼數職)

而這中間很多事情都牽扯到人,許多人與人之間的溝通,行為,互動,思考等,所以『網站開發』這件事情也就變的不是這麼容易。(畢竟牽扯到人的問題,就是一個很大的問題)
邏輯,程式什麼的重要嗎? 對於網站開發,對於一個好的網站設計師,程式設計師兩角色來說,邏輯的清晰是需要的,而且必要存在心中。

畢竟網頁目前需要符合在不同載具(手機,平版,電腦等),為了要一體適用所有情境,就會有所謂的規範,才有辦法讓這麼多不同的尺寸解析度條件下,達到最小標準,讓使用者可以在不同載具上進行閱讀,互動。(RWD)

但是至於程式功力是不是要很強大!?這可能就要看需求,以及這個網站的目的,也許要,也許不用。(沒有標準答案)
要如何進入這個領域熱情,熱情還是熱情!

對於自己來說,網站開發…