2015年12月31日 星期四

什麼是設計?


 Design Q&A by Charles Eames 中譯

Q: 你對設計的定義是什麼?
A: 人們可以將設計描述為安排元素來達到特定目的(purpose)的計畫。

Q: 設計是一種藝術的表現嗎?
A: 我寧願說是一種目的的表現。它可以... 如果它足夠好,之後會被判斷為藝術。

Q: 設計是一種為了工業目的的工藝嗎?
A: 不是,但是設計也許是某些工業問題的解。

Q: 設計的限界是什麼?
A: 問題的限界是什麼,設計的限界就是什麼。

Q: 設計是只關注一部份環境(environment)的學科嗎?
A: 不。

Q: 它是一種通用表達的方法嗎?(Is it a method of general expression?)
A: 不,他是行動的方法。

Q: 它是一個人的創造物嗎?
A:  不,事實上每個人都會受到前人的影響。

Q: 設計是團體的產物嗎?
A: 通常是。

Q: 有設計倫理嗎?
A: 設計總是有限制,通常也包含倫理這項。

Q: 設計意味著產品是有用處 (necessarily useful) 的嗎?
A: 是的,即使用處可能很微小。

Q: 人們可以光為了樂趣的作品合作嗎?
A: 誰會說樂趣是無用的?

Q: 設計的過程中要承認限制嗎?
A: 設計和限制有很大的關係。

Q: 什麼是限制?
A: 設計問題的有效關鍵:設計師能辨識出越多限制越好、他的對於這些限制一起工作的意願和熱情。限制像是金錢、大小、強度、平衡、表面材料、時間。每個問題都有它自己限制的列表。

Q: 設計是短暫的嗎?
A: 有些需求是短暫的。大部份設計是短暫的。

Q: 該朝向短暫還是永恆的設計前進?
A: 如果是一般性、通用的需求和設計,會朝向永久。

Q: 設計是為了誰?
A: 需求。

Q: 你曾經被迫接受妥協嗎?
A: 我從未被迫妥協,但我樂意接受限制。

Q: 練習設計的首要條件是?
A: 辨認需求。(Recognition of the needs.)

看完影片大概知道,設計和目的、需求、問題、限制是息息相關的。

---
接下來看維基百科上對  Design 的定義。定義來自這篇 paper - A Proposal for a Formal Definition of the Design Concept by Paul Ralph et. al. 

他提出來的定義如下


Design

(noun) a specification of an object, manifested by an agent, intended to accomplish goals, in a particular environment, using a set of primitive components, satisfying a set of requirements, subject to constraints;

(verb, transitive) to create a design, in an environment (where the de- signer operates) 

看了應該不知道想表達什麼,所以他畫了張圖,這樣就清楚多了。

Agent 是設計的人。
產出(Output):對某個物件的規範/規格
然後這個 Output,要完成某些目的 (Goals)、受到某些限制、滿足一些條件、產出在某個環境、由一些元素所組成。

舉例來說:

平面設計:指的是設計的的產出位在的環境是 2D 平面。

服務設計、字型設計、介面設計、使用者體驗設計、服裝設計:指的是它們的產出 (Specification of Object) 是什麼。

物件導向程式設計:指的是 primitive components 是物件、產出是程式。

使用者導向設計 (UCD):指的是設計的產出的目的 (Goal) 和使用者有關。

作者進一步用動詞來看設計,畫了這個圖,清楚地標明什麼是設計這個動作的輸入 (Input) 和輸出 (Output)
最後他又把這個圖改寫成設計的新定義


design activity as a process
executed by an agent
for the purpose of generating a specification of an object based on: 
> the environment in which the object will exist, 
> the goals ascribed to the object, 
> the desired structural and behavioral properties of the object (requirements), 
> a given set of component types (primitives), 
> and constraints that limit the acceptable solutions. 

有沒有很複雜?簡單說 「設計活動就是在某些限制下,生出某個東西來達成某個目的的過程。」
好像在說廢話有沒有~~~ XD

什麼是設計?


 Design Q&A by Charles Eames 中譯

Q: 你對設計的定義是什麼?
A: 人們可以將設計描述為安排元素來達到特定目的(purpose)的計畫。

Q: 設計是一種藝術的表現嗎?
A: 我寧願說是一種目的的表現。它可以... 如果它足夠好,之後會被判斷為藝術。

Q: 設計是一種為了工業目的的工藝嗎?
A: 不是,但是設計也許是某些工業問題的解。

Q: 設計的限界是什麼?
A: 問題的限界是什麼,設計的限界就是什麼。

Q: 設計是只關注一部份環境(environment)的學科嗎?
A: 不。

Q: 它是一種通用表達的方法嗎?(Is it a method of general expression?)
A: 不,他是行動的方法。

Q: 它是一個人的創造物嗎?
A:  不,事實上每個人都會受到前人的影響。

Q: 設計是團體的產物嗎?
A: 通常是。

Q: 有設計倫理嗎?
A: 設計總是有限制,通常也包含倫理這項。

Q: 設計意味著產品是有用處 (necessarily useful) 的嗎?
A: 是的,即使用處可能很微小。

Q: 人們可以光為了樂趣的作品合作嗎?
A: 誰會說樂趣是無用的?

Q: 設計的過程中要承認限制嗎?
A: 設計和限制有很大的關係。

Q: 什麼是限制?
A: 設計問題的有效關鍵:設計師能辨識出越多限制越好、他的對於這些限制一起工作的意願和熱情。限制像是金錢、大小、強度、平衡、表面材料、時間。每個問題都有它自己限制的列表。

Q: 設計是短暫的嗎?
A: 有些需求是短暫的。大部份設計是短暫的。

Q: 該朝向短暫還是永恆的設計前進?
A: 如果是一般性、通用的需求和設計,會朝向永久。

Q: 設計是為了誰?
A: 需求。

Q: 你曾經被迫接受妥協嗎?
A: 我從未被迫妥協,但我樂意接受限制。

Q: 練習設計的首要條件是?
A: 辨認需求。(Recognition of the needs.)

看完影片大概知道,設計和目的、需求、問題、限制是息息相關的。

---
接下來看維基百科上對  Design 的定義。定義來自這篇 paper - A Proposal for a Formal Definition of the Design Concept by Paul Ralph et. al. 

他提出來的定義如下


Design

(noun) a specification of an object, manifested by an agent, intended to accomplish goals, in a particular environment, using a set of primitive components, satisfying a set of requirements, subject to constraints;

(verb, transitive) to create a design, in an environment (where the de- signer operates) 

看了應該不知道想表達什麼,所以他畫了張圖,這樣就清楚多了。

Agent 是設計的人。
產出(Output):對某個物件的規範/規格
然後這個 Output,要完成某些目的 (Goals)、受到某些限制、滿足一些條件、產出在某個環境、由一些元素所組成。

舉例來說:

平面設計:指的是設計的的產出位在的環境是 2D 平面。

服務設計、字型設計、介面設計、使用者體驗設計、服裝設計:指的是它們的產出 (Specification of Object) 是什麼。

物件導向程式設計:指的是 primitive components 是物件、產出是程式。

使用者導向設計 (UCD):指的是設計的產出的目的 (Goal) 和使用者有關。

作者進一步用動詞來看設計,畫了這個圖,清楚地標明什麼是設計這個動作的輸入 (Input) 和輸出 (Output)
最後他又把這個圖改寫成設計的新定義


design activity as a process
executed by an agent
for the purpose of generating a specification of an object based on: 
> the environment in which the object will exist, 
> the goals ascribed to the object, 
> the desired structural and behavioral properties of the object (requirements), 
> a given set of component types (primitives), 
> and constraints that limit the acceptable solutions. 

有沒有很複雜?簡單說 「設計活動就是在某些限制下,生出某個東西來達成某個目的的過程。」
好像在說廢話有沒有~~~ XD

2015年12月20日 星期日

台大不一樣思考社:設計思考工作坊 Day 2

組合虛擬人物 (CC)

第二天一早 Recap 的方式就是,從前一天的三個人物中合成一個叫 Jessica 的虛擬的人物 ( Composite Character ),這部分是很主觀的,先基於從現有列出來的 needs 和 insight 選出覺得有發展性的點。最後再藉由腦補內容、畫使用者畫像,像是 Persona 一樣把虛擬人物立體出來,因為花了一整天生出來的人,大家其實對他很熟悉 ( 比隨意的 Persona 熟的多 )。

腦力激盪  (Brain Storming )

CC有幾個 insight,最後選的 insight 是現代人會 Do something 來填補早餐的空白時間、像是滑手機,所以腦力激盪的目標變成就是想出一個「讓早餐時間不是空白時間」的方法。之後就是「不批評」「不打斷的」「不離題」的 Brain Storming 了。因為有了 Jessica,這個每個人都熟悉立體人物,溝通的時候變得方便很多,就像是有了使用者的原型一樣。Brain Storming 就是爽爽的啊,不過這次特別強調了「要延伸」他人想法、「要畫圖」要有「Title」等重點。

發想的差不多後,用「強迫聯想」的方式做 Brain Storming,這部分也是蠻新奇的,先列出「教室」和「辦公室」裡的不相干用品,然後強迫生出可以滿足人物 insight 的想法,這邊會先卡住,然後只要有人開始分享,就會變得很多神奇的想法出來。最後再把所有的想法大概有 100 個吧,一人數票投票列出幾個、然後在二次投票,二次投票的時候才想起 Jessica,想哪一個想法比較可能滿足她。最後選擇用動的食物吸引注意力的迴轉壽司早餐。(好像是小隊輔提出來的... XD) 還有設定要驗證的幾個小想法,像是少量食物、多樣組合 blah 的

製作原型 (Prototyping)

快樂的 30分鐘 maker 時間,高級的扮家家酒和演戲,多次試驗。大家都玩開了~ 我只能說大家的手做能力很強大。

請使用者測試 ( Testing )

這步真的讓我看到 Prototype 的威力所在,第一個使用者就發現這個原型對使用者的感覺,雖來一進來就盯著移動中的食物,但跟我們思考的不一樣。因為迴轉壽司早餐比較像是有空閒時間才會去的地方,對想省時間的使用者。另外還有會發覺原型的問題,像是輸送列應該一開始就要有早餐在上面、最好加上文字說明。除了輸送列的早餐外,還要有菜單、送茶水的服務生不用帶位,特別強調是週末,悠閒的週六早上十點之類的情境。修一修加上演戲,原型多少有解到空白時間的問題,在第一個 iteration 應該算是不錯吧。

各小隊火力展示 ( Demo )

很意外的是其他六隊都做 App,而且有試著嘗試去解我認為早就被解完的問題:「有效率地得到早餐。」本來以為台灣早餐店林立、便利商店林立,早餐不用跑很遠、更不用自己做,還會剩下什麼需求沒被滿足嗎?結果是「熱騰騰好吃的早餐店要排隊」,於是就寫個注重體驗的訂餐、捷運門口取餐的App,然後第一次實體看到 App 的 Prototype長什麼樣子,點點點、換頁之類的,想到我做網頁、寫 App 錢真的也該先做好 Prototype 找個使用者來用用啊~~~

結語
這個工作坊是個團隊討論、體驗設計思考流程的好地方。本來以為價位有點高 ( 和我以前辦其他社團活動比 )。不過看到一組請三個陌生人使用者來受測、中午吃的還不錯、設計 conference 都很貴、1:2 的教練學員比,總總因素來說是 C/P 還不錯的。列一下 pros and cons:

pros:

  • 可以深入的練習觀察技巧
  • 思考使用者的需求和需求背後的原因
  • 快樂的團隊思考、討論體驗
  • 大量便利貼的利用技巧
  • 得到一種完整的設計流程體驗
  • 真實的和使用者接觸
  • 小隊輔們還蠻用心的
  • 可以碰到許多願意用溝通、用設計改變世界的人
  • 小遊戲很好玩
  • 一直放舞曲很High

cons:

  • 和現實真的有一段距離 (感覺 TA 是學生)
  • 像「人本機構」的只鼓勵、不批評的環境讓「擁抱失敗」變成口號。
  • 建立「需求」、「insight」、「CC」,的過程中用了大量的假設,推論一錯就 GG
  • 完全不做現有解法的比較與調查 (像是摩斯訂餐 App)
  • 不介紹失敗的例子
  • 過度強調人本,但除了人的需求。技術和商業的重要性都不說明,一個好的偵探除了觀察和推理能力,對事物的知識也是很重要的。
  • 只有練習三個人以上的團體技巧。
---
有點小進步,不過感覺和 Design Researcher 的路還有好遠好遠。
最後有點太專心討論和解題,好像沒有好好認識其他人啊,有點可惜~

心理系的小隊輔一江、設計感的 Jarah、到處出現的 Boy、強大的設計師 美辰、很有主見的獸醫系 元皓、講話有趣的東璋、眼鏡很帥的財金系 軒凱、討厭心智圖但會組織演講的柏儒,這次有點忘記一期一會的決心...

記得感到痛苦和累的時候,稱讚一下自己吧「你努力離開舒適圈了喔 :p」

2015年12月19日 星期六

台大不一樣思考社:設計思考工作坊 Day 1

和藝術不同,設計是一門客觀的學問。重視觀察、基於觀察做出像偵探一樣的推論、做出像科學家一樣的假設,用同理心而不是同情心去理解這一個人的行為和需求、從使用者的角度去看這個世界。

問題是和需求是不同的:

從8層樓高優雅的降落到地表不受傷是一個問題。但大多數人這輩子都不會有這樣的需求。


需求要用動詞來描述而不是名詞:
需求:「吃到好吃的早餐」 => 人自動會把行動連接成
  1. 怎麼 「吃到好吃的早餐?」
  2. 為什麼要 「吃到好吃的早餐,原因是什麼?」
需求「好吃的早餐」 => 推理就的莫名其妙的卡住,加上 5W1H 都很不順!




今天請大家解的題目是「如何提升吃早餐的經驗」。

流程:
   1. 先用便利貼討論要訪談使用者的問題、把相近的問題Group後,針對每一類問題畫正字投票.

   2. 街訪:會有一個主訪、副訪和紀錄。大概十分鐘,主訪負責掌握進度、副訪負責見縫插針。

   3. 把數個人紀錄的資訊口述下載,每個人寫下事實 (Fact) 到便利貼上 & 分類。

==== 以下開始小組討論、瘋狂的 blocking I/O 超花時間,為什麼不繼續平行計算啊 ====
   4. 試著從事實 (Fact) 中,推出這個人的需求 (need)
   5. 從這個人的需求 (need),找出洞察  (insight)

[來到了 long long complain section]
一人一票決定街訪問題,真是不太好,就是一種讓人膚淺思考的快速解決方式吧、然後想問題的時候,好像沒有一個比較好的想法,怎麼問會得到提升早餐經驗的資訊,不過強調 empathize 那這次就不預設立場試試吧

從列需求就一直卡,用動詞描述真的很重要 ( 回家才看文章才懂 ),然後訪的幾個學生都不是很愛吃早餐,他們的簡單需求早就在這個台灣早餐文化發達、便利商店充斥的環境滿足了。還說「提升早餐體驗」是簡單題目,結果需求列完,洞察完全列不出來。需求出來就解啊,為何要落在為做「設計思考」強說洞察的陷阱裡,Inception 一定要下到第幾層嗎?不過別組有些很順利的,希望明天報告的時候能搞清楚,我們和別人不同在哪?做錯了哪一步?

另外一個是「提升早餐體驗」的題目定下來了,我們不知道客戶是誰、沒有辦法詢問客戶,沒法想問題背後的問題 / 找到真正要解的問題。然後一開始也沒決定是要生產品還是服務,也沒有定好 TA。最後我們這組 TA 好像是學生,但如果要解這個問題,自身的經驗、非訪談的觀察就不能使用。

然後很討厭,台上報告有事沒事後面工作人員就很 high 的附和之類的,做設計一定要這樣搞嗎?不過開始前玩小遊戲提神真的還不錯。

現在的想法就只有,使用者都想跟朋友一起吃早餐,那就請宿舍早餐店提出兩人同行,第二人早餐六折的優惠,這樣所有人的體驗都會好,早餐店也會比較賺錢。

---
現在只能安慰自己,花了 1,600 元兩天就發覺 Design Thinking 沒啥用,也是不錯的收穫,反正還有一堆其他的設計流程。 UX 這條路 QQ 回家重看了設計的心理學的 Design Thinking 一章,特別強調不要用訪談耶...Orz


Don't try to be original, just try to be good.
I don't want to be interesting, I want to be good.
( 不一樣思考又怎樣啊... 解問題為什麼不先 google / survey? )


明天就是嘴砲的 brain storming~ to be continued.

延伸閱讀:
像福爾摩沙一樣解決社會問題 (同情心、同理心、觀察力)
Problems Are Not Equal to Needs
Don't try to be original, try to be good.

2015年12月6日 星期日

Firebase:前端工程師的神兵利器

Firebase.com 像其他的「後端即服務」( Baas, backend as a service ) 一樣,不過他的 Tutorial 超簡單,你只要會用 node 的 npm 大概就夠了。

Firebase官方超簡短教學,看了這個我就被吸引住了。

React 讓人解決 MVC 中的 View。Firebase 讓人不用建 server、遠端登入,只需要用 web user  interface 就建出以 Json 為格式的即時資料庫、Rest Web API、One command deploy ( firebase deploy )、社交帳號的管理 ( Oauth 介面的 Facebook、Google、Twitter blah blah 的登入管理) ,還有靜態 CDN 資料發佈、Custom domain mapping ( 這個要花一點時間等 DNS Propagate )。

Firebase.com 去年被 Google 買走、Parse.com 前年被 Facebook 買走、Apple 也推出了自家的 CloudKit,這些「後端即服務」的公司,讓你 不用再管 Server & 資料庫。你只需要有整理資料的能力 ( Structure Data ) 和前端設計的能力,就能當全端工程師了 :)

各家都有基本的免費流量,一個月 100 GB ~ 2TB 都有,但一旦升級之後就會變很貴喔 要小心。簡單說,以後 Hackathon 不用找後端工程師了,也不要再傻傻的去 github 找看都看不懂的 Hackathon Starter Kit。

---
真心覺得,Startup 剛開始用 Baas 就好,省 Server 和後端工程師的錢。

2015年12月1日 星期二

React UI 心得文之一

這週在忙著刻一個大元件,中間有包兩三個中元件、然後中元件下面又會有小元件。要記得React 是負責 UI 的啊,千萬個不該在小元件裡面存 state。存了改了兩天還是會有問題,小元件如果存了狀態,常會有那大元件重 render 的時候,設 property 卻無法更新小元件,因為小元件的 state 不一樣了。兩天之後把大中小元件全部改成 dumb component 真的快樂的不得了,程式碼變少了、邏輯也清楚了。


刻 React 元件的方法:

  1. 盡量刻 Dumb Component,把它當成 function 去想要提供什麼參數
  2. parent component 要對 child componet 命名和設 handler(childId, value)
  3. 事件發生時就呼叫 parent 傳來的 handler,說你是哪個 child和發生了什麼
就這樣遞迴做下去,最上層的 App component 就可以知道,哪第三個child component 的第四個 child component 發生了什麼事,然後做一些處理。


客制化 React 元件外觀的方法:
  1. 幫元件的各種 property 類別放置對應的className
  2. 用 webpack 的 css loader 幫元件建立 local 的 css scope,然後用一個 scss 檔去管理一個元件,這樣一切都會輕鬆的多。( 參考 React Toolbox )
其他刻外觀小心得:
  1. 多用 em, rem
  2. 用 css 幫背景上色的方式,快速看物件是否對齊
  3. 用 Mac 的放大鏡 ( ctrl + 雙指滑動 trackpad )
  4. 用 css trick cursor 去引導 behavior
  5. 用 font-weight 和 color 的 alpha channel 去做細部微調
學各種 React 相關 Library的方法:一定要從看完官方的 Tutorial/Guide 開始,網路上的介紹文章通常都挑簡單的地方說,十篇有九篇都講一樣的東西,還不如看官方的 Tutorial/Guide 把重要的東西有系統的一次學會。很重要所以特別粗體一下...

使用者經驗部分:

碰到客戶想要重新客製化系統的時候
  1. 照他們舊有的行為,模擬跑自己刻的新系統幾次,很快就可以知道缺了什麼、哪裡會生出問題,這樣的方法比在那邊天馬行空的猜測會方便的很多。例子: 新報表系統拿舊系統的許多報表重新打一次。
  2. 用心智圖的方式窮舉可能的行為,不然光是用腦袋想一定會漏掉很多細節。

和他人合作的部分

一定要定時 Sync 進度,時常 commit。不要隱匿進度落後、缺失、維護 local state,想說這樣可以加班追回來。因為很多事從他人的角度來看會清楚的很多,也方便別人調整。不要裝弱、裝強,快放棄那沒用的自尊心吧。

2015年11月27日 星期五

聊預測自己未來的能力

比起預測下一期大樂透號碼的能力,這邊說的「預測未來的能力」跟「對未來的想像力」比較相關,是更日常生活相關的能力,。

這個故事是我最近一個月經常發生的事,剛剛又發生了。我經常會有沒洗澡就睡覺,隔天要出門去咖啡館寫程式的情況,這時就想還是洗一下澡好了、但為了時間還是不要洗頭好。但進入浴室在熱騰騰的蒸氣中間,就會想熱水洗頭會很舒服,然後就洗頭,舒服的回到房間,吹個頭舒服的弄很久才出門。然後隔天出門時又做了一樣的規劃,嗯 洗澡但不洗頭。

這故事跟個人工作能力無關,但卻大大了影響了我工作的計畫和效率。我缺乏的是清楚地理解自己在不同環境中,會受到怎樣的環境影響,就簡單地做出計畫。

如果我清楚地想像就算「現在做了決定不洗頭,等下還是會洗頭」,那在趕時間時,我就會決定不洗澡就出門。如果我清楚地想像到「現在在浴室中洗了頭,會舒服到等下在房間吹頭髮、花半小時東摸摸、西摸摸」,那我可能就會忍住不洗頭。

在這個小故事中影響不大。但在現實工作中,一樣會有這樣的情況。像是被問「這東西下個禮拜做得出來嗎?」腦袋中的想像是每天加班,努力工作,然後下週準時交差。但現實是,加班個兩天,發生了一些問題、或是加班三天後沒心情工作,這些都和你寫程式的能力無關,但卻會在你承諾的時間交不出東西,拖累整個團隊。


對自己能力過於樂觀的估計是大忌!!! 會拖累他人進度。

對自己能力過於悲觀的估計是大忌!!! 會拖累自己成長步調、不敢嘗試。

這種想像力、對過去歷史的記憶力、也許是可以訓練的。再不然只對自己一定能預測正確的情況做預測,其他情況就清楚明白的放在「不知道」這個類別。

俗話說得好「人貴自知,知己者明」。
努力認識自己吧~ 培養自知之明。

參考:《老子》第三十三章:「知人者智,自知者明;勝人者有力,自勝者強」
---
BTW, 這個能力是很容易被觀察的,只要看一個人有沒有準時完成他的承諾就知道了。


2015年11月20日 星期五

程式設計法與人生 (Programming Paradigm and Life)

解決問題流行的方式有兩種。
  1. 想出第一步要做什麼,然後開始做、做完再想下一個。
  2. 是把大問題切成數個小問題一直切到夠小,然後再一個一個做。
第一個 叫做命令式程式設計、第二個 叫做宣告式程式設計。
第一個 想要回答「怎麼做」、第二個 想要回答「做什麼」。
第一個 是工程師做的事、第二個是設計師做的事。
第一個 叫做敏捷式開發流程、第二個 叫做瀑布式開發流程。
第一個 叫做 connecting the dots、第二個叫做 設計研究。
第一個 叫貪婪演算法、第二個叫分治演算法。
第一個 叫活在當下、第二個叫有遠見。
第一個 把問題序列化、第二個把問題 心智圖化。

用第一種的人想出了外掛 - 設計模式 (design pattern)
用第二種的人想出了外掛 - 狀態機和不變資料 (state machine + immutable data)

還記得大二演算法排序的作業,標準解法是先做第二個 (qsort)、然後問題變小了就接第一個 (shell sort)

各有各的使用時機,冷靜分析後我從函數式編程的信仰者回到無神論者了。
第一個適合許多未知、經常變動的問題。
第二個適合有固定答案、行為可預測的問題。

嗯嗯 不過當然用 react 還是比其他好 XD
---
目標努力 iterative 的 functional programming~ 
=> 每次用第一個方法切一小塊問題,用第二個方法解。

2015年11月15日 星期日

參加 FB Hackathon 2015 感想

FB Hackathon 比賽篇

有點缺乏結束的感覺,這時候放下再前進的方法就是寫篇文,透過寫作把事情組織、整理好。

這是我第一次參加 Hackathon,這次是 FB 和 Girls in Tech 合辦的,主題是女性和公益。先不論結果、這次真的很新鮮 ( 趕期末作業的 fu ),之前上網研究過的 Hackathon 攻略,但今天完全丟在一邊沒在管... 哈哈

大家在交誼區自我介紹、聊自己的想做的主題,結果弄了很久大家有一點點熟,到一張桌子旁邊坐了下來就變成一隊!!! 然後我們這隊大部份都是做後端、資料處理的,結果就是 nodejs + java + python 各種語言混合大亂鬥,真的很酷~

經過聊天,發現大家都是第一次參加、發現大家都是熱心公益的人。前面三個小時,花了長時間 Brain Stroming,一般會得獎的參賽者都是決定好要做什麼才來的,還有偷做的。在 Hackathon 跑快速 BASIC 設計流程真的很神奇,定義問題 (Briefing)、分析已有解法 (Analysis)、思考改進方法(Synthesis)、實作 (Implementaion)、傳達 (Communication)。大概流程都有跑,不過 S & I 的部分有點亂。其他合作流程都有讓人 Hack 團隊的感覺。

一直看設計研究的初學者,終於有個玩的機會 XD~ 很多不熟的地方,設定 Target Audience、設計 Magic Moment ( 這個沒做... )、列出 User Story ( 這個也沒做... T.T )、設計互動 ( 光流程不算... )、紙牌分數投票法。設計師注重這問題是不是真正的問題,工程師注重的是這問題要怎麼解,Hacker 的精神在這兩個中間。但年紀大了真的開始變得比較嘴砲了... T.T

我這天在工程師的部分一直撞牆,真的是... 超弱。Node & Express 才摸一週多、Facebook APP 第一次開發 ( 這個真的超多地雷限制 )、mongodb 第一次用、環境設定在 Macbook 卡一卡、在 linode linux server 卡一卡。就像馬拉松配速沒配好一樣,在經過三小時討論、五小時 Coding,我在最後的四小時完全失去戰鬥能力。壓垮我的稻草是從 Facebook 抓圖隨機一直回傳 403。

真的很感謝強者隊友們,PeiPei / Gordon / Joanne / Leo / Erica,就 12 小時 sprint 的角度來看,第一次還蠻成功的,如果再 iterate 幾次、這個團隊應該會生出好產品的。今天過程真的很好玩~ 有了好同伴,就從在 Panic Zone 變成在 Learning Zone 了。

會再參加嗎?喔 真的很累,想到下個月還有一場就很崩潰。

Hackathon 前問題研究篇

因為主題是女性和公益,賽前大概花了半天看了很多議題,挑出兩個覺得適合的問題。

1. 增加同理心 (empathy) & 跨出舒適圈 (Comfort Zone) 的主題:
    > I don't like that man. I must get to know him better. - 林肯
    > While nothing is easier then denounce the evil doer, nothing is more difficult than understand him. - 杜斯妥也夫斯基
    > Step outside of your tiny little world. And step inside of the tiny little world of somebody else. - Sam Richards
    > Life begins at the end of your comfort zone.
    > comfort zone / learning zone / panic zone
    > Ted影片:一個關於同理心的激進實驗
    > 厚書: 好人總是自以為是:政治與宗教如何將我們四分五裂


2. 在東亞,特別少女生走自然組:不是因為能力不同、而是因為社會期待。 ( 昨天才突然發現我修大學資工系的課時,從來沒跟女生共事過 )
    > 台灣女生不喜歡讀科學,「世界第一」帶來的驚愕與警訊
    > 高中選組男女大不同?性別與高中選組之研究


好好放下、明天再前進 Javascript 和 函數編程的世界、Full Stack Developer 之路。
---
延伸閱讀:10 tips for hackathon success

2015年11月10日 星期二

做 Prototype 的工具 framer js



今天逛到一個設計聚會的臉書頁面,他們投票最想學的 Prototype Framework 是 framerjs。一點進去他們網站看,就發現了學 React 一直很缺乏的 Animation 和設計感。後來也發現 React 也有人做 Animation,今年的 ReactEurope 有兩個很好的 Talk,不過先來看這個影片,進修一下、看這個影片教設計師的 prototype 的方法吧。

framers 是一個創意設計的工具,讓你能建立互動和動畫的 prototype。為什麼要做 prototype?探索和發明新的互動、定義要設計出的感覺是什麼、做有效的概念溝通。

對我來說最有趣的部分是當你從你的設計中建出互動的 prototype,你會發現很多全新的互動。如果你只是做靜態的 mockup,然後叫其他人做一些 Animation,你會失去跟它玩的機會... 試著反過來做、亂玩參數、試著發明東西。對我來說,這是 prototyping 中最有趣的地方,總之就是東搞西搞一些。

另一件事是當你談到設計,除了視覺設計外還有很多東西,當你開發 App 或是網頁,更要在意的是它感覺起來怎樣,怎麼互動、怎麼流動,很多視覺設計以外的東西。

另一件很實際的是當你在團隊中工作,prototype 能讓你很有效的其他人溝通你的新想法。今天我可在這邊給個好例子:「想像你有一個可排序的列表,被選擇的項目會放大和加陰影浮在上面。所有的項目都會對此改變它們的位置。」

下一步你會做一堆速寫

然後是精美、有陰影的 Mockup 


但我們真正接下來想看到是有動畫能互動的 Prototype
試著做一些操作,移動項目


animation:after effect / keynote
prototyping: ... 一堆,最後一個是framer
 我們今天想著要 prototype 什麼,它實際上就是在設計明天。從概念到執行中間大概可以分成四個階段:Paper -> Sketch / Photoshop -> Framer -> Code。以流程來說,Prototype 大概是在正中間的位置。Prototype 可以往前或往後一點。現在的產品設計流程,通常會做很多靜態的 mockup 但只做一個到兩個 Prototype,我們希望有了更好的 Prototype 工具之後,可以變成三五個 mockup 但做很多的 Prototype。

Framer js 是一個開源的程式庫,提供 Framer Studio Mac App:它提供程式碼編輯器、即時視覺回饋、可以從別的軟體 Import、展示模式。

Framer Studio 可以直接從 Sketch 導入 layer、階層。


Framer 提供這些功能。
Layer 就是一個 Container 可以設定大小、位置、透明度、縮放、圖片、模糊... 一堆屬性。
Animation 讓你從一組 states 過渡到另一組 states。可以設定 curve、延遲、時間長度。
States 讓你命名一組 states,之後你就可以指定從 XXX 變成 YYY。
Events 讓你可以處理 drag、drop、click、scrolling、touchstart ...

開始 Demo Prototype examples & QA 從影片13分15秒。

---
framer 教學影片:https://www.youtube.com/watch?v=3zaxrXK7Nac

從影片中可以看到,設計師是直接把一整張圖當成 Layer 來操作。然後視覺上的元件就當成自訂元件,不用管甚麼 HTML / JSX,然後就對視覺上的這個元件 ( 一張 button 的圖 ),安上click 事件,然後用動畫把另外一張圖換上來...

設計師設計時用不同大小的圖片當成自訂元件,以這樣的元件視角去設計整個 Prototype,看是這張圖要不要模糊、要浮在前面還是後面、要不要讓他可以 Scroll、動畫時要如何從一個 State 變成另外一個 State。

這樣子好直覺啊,一個元件就一張圖,用 sketch 畫畫就好,不像程式設計師要用 HTML / CSS / UIKit 兜好久。


framer 教學影片 https://www.youtube.com/watch?v=kJYI4oYrHik
他們的 script 語法好簡單,超簡潔、超適合簡單的 UI,像 Python 用 indent 代替大括號真的很棒,然後設定 Event 也太簡單。都在操作 Image 超簡單。

發現那個 script 叫 coffee script 喔喔喔 看了完全不想寫 Javascript了 XD

2015年11月9日 星期一

函數式編程介紹 ( 1 / 2 )

函數式編程的專有名詞篇


純函數 ( Pure Function )給同樣輸入參數,就會回傳同樣結果的函數,而且沒有任何可觀察到的副作用。Pure Function 的例子:sin(x)。非 Pure Function 的例子:getChar()、random()、還有許多類別中的 member function。從數學上來理解,純函數就是一個數學函數,一個輸入會對到一個輸出。

純函數的特點:
  1. Portable / Self-Documenting :完全是自給自足的 ( self contained ),沒有外在的依賴 (Dependency)。
  2. 可暫存 ( Cacheable ):把計算值暫存的技巧被稱作 memorization,可以用來避免重複計算,加速程式。
  3. 好測試 ( Testable ):不需要管上下文和呼叫順序就可以測試。
  4. 適合平行處理、純函數是線程安全的 ( thread safe )。
  5. 引用透明 ( Referential Transparent ):一個引用透明的運算式指的是 如果這個運算式可以被他的值 (回傳值) 替換而不影響整個程式的行為。簡單講就是有可交換性啦。
  6. 可以熱抽換 ( Hot-Loading ):因為不依賴外部的狀態。

副作用 ( Side Effect )如果一個函數或運算式 ( expression ) 被說有副作用,這指的是它改變了一些狀態 ( states ) 或是 跟呼叫他的函數或外在世界,有可觀察到的互動。舉例來說,一個函數可能會改變全域變數或函數的靜態變數、改變傳進來的參數、引發例外 ( exception )、列印資料到螢幕或是呼叫了其他有副作用的函數。如果有了副作用,函數的行為會受到歷史、執行順序的影響。這樣子一來,想要理解或除錯有副作用的函式會較難,因為就必須要了解他的上下文 ( Context ) 和執行歷史。

顯式 ( Explicit ):形容函數与外界交換資料只有一個唯一管道——参數和回傳值。和顯式的相反是隱式 ( Implicit )。

一級函數( First-Class Function ):指的是語言支援把 Function 當成第一類公民,可以支援一般變數的操作,像是把 Function 當成變數傳給另外一個 Function。

Lambda Function:Lambda 運算式是匿名函式,可用來建立委派或運算式樹狀架構類型。

形式系統 ( Formal System ):形式系統可以的廣泛地被定義為任何基於數學模型的、良好的抽象思考的系統 ( system of abstract thought )。

Currying:這個技巧能把接受多參數的函數轉換為多個連續呼叫的單一參數函數。

閉鎖 ( Closure ) / MDN:Closure 是可以使用獨立 / 自由變數的函數。換句話說,Closure 記得它實體化時的環境變數。

PS:專有名詞那邊引用了很多別人的解釋,可以點前面的連結進去看完整版。

-----------------------------------------------------------------------------------------


函數式編程簡介篇

函數式編程的的哲學就是假設副作用 ( side effect ) 是不正確行為的主要原因。所以努力想要控制和管理副作用,經常的解法就是把純函數、單子和不純的函數 ( impure function ) 分開來管理。另外鼓勵大家多寫純函數。我們對待資料要像玩戲法般,一直傳來傳去、禁止使用狀態 ( state ) 和副作用。剛剛這段文字有提到很多專有名詞,但這樣子怎麼寫程式?這邊我開始介紹一個新工具叫 柯里化 ( currying )。

Currying:
Currying 把任何的函數轉換成 一連串只做單一事情的函數,各個擊破。

Curring的概念是簡單的。它讓你呼叫函數 A 時可以傳比預期還少的參數。然後這個函數 A 會回傳函數 B函數 B 需要的參數是先前沒傳進函數 A 的參數。所以整個流程是:

函數A (x, y) 可以等價於下面這段
-------------------------------------
函數B = 函數A (x)
函數B (y)

先前傳進去函數 A 的參數會利用閉鎖 ( Closure ) 的方式變成函數 B 的環境變數。看完上面這段解說,一定會想這什麼鬼東西?來看看 這邊的例子 會容易理解的多。利用這個技巧,就可以選擇一次傳所有參數或是把參數分幾次傳給數個函數。

lodash提供了把函數 curry化的工具,用法:

var divide =           function (x,y) { return x / y } 可以被改寫成
-----------------------------------------------------
var divide = curry( function (x,y) { return x / y } );

之後就可以被這樣呼叫

divide ( x ) ( y );

或是

var xDividedBy = divide ( x );
tenDividedBy ( y );

PS:這工具的名字是為了紀念一個美國數學家 --- Haskell Curry,跟咖哩沒有關係。

接下來我們看另外一個工具 代碼組成( compose )。

組合 / 組成 / 合成 ( compose )
Composition 把許多函數用管子 ( pipe ) 連接起來,變成一個新個函數。


f, g 都是函數,x 在它們之間被傳遞。
注意g函數的參數是 x、f函數的參數是 g函數的回傳值。
較常用在 f & g 都吃同一類參數的時候 (ex: 字串)。


例子:變大寫和去空白函數 = compose (變大寫函數, 去空白函數)

因為有了一級函數、Currying、組合,Pointfree 風格變得流行了起來,指的是函數呼叫時不用提到它要處理的資料。例如:

var snakeCase = function ( word ) {
      return word.toUpperCase( ).replace( /\s+/ig, '_' );


可被改寫成
-----------------------------------------------
var snakeCase = compose ( replace( /\s+/ig'_' ), toLowerCase );

用組合形成新函數就不用提到資料 --- 也就是之前寫法中的 word

Pointfree的編程風格可以讓我們移除不需要的名字 (names),讓我們保持簡潔 ( concise ) 和一般化 / 泛型 ( generic )。但要小心 Pointfree 是個雙面刃,有時會把原來的目的變得模糊。

( 以上是書本前五章的內容,其他待續... 後面有點硬,不知道什麼時候會看。)

---
這篇文介紹得很好 函數式編程

2015年11月8日 星期日

Javascript 中的函數式編程 (a talk @ ReactiveConf 2015)

影片:Functional Programming in Javascript By Daniel Steigerwald 

Daniel 是 google 前員工、也是 https://github.com/este/este 這個 React + Redux + immutable.js Starter Kit 的作者,在 Github 上有 1800 顆星。

我認為函數式編程 ( Functional Programming ) 將在明年成為主流。像在 C++11 和 Java 8 中已經開始有 lambda function。我接下來聊我已經用在 Production 的東西。我認為函數式編程已經在前端的世界已經被 React 引入。

什麼是函數式編程?
沒有什麼神秘的東西,到處都是純函式 ( Pure functions everywhere )、不可變的數值 ( Immutable values )、用組成而不用繼承 ( composition over inheritance )、紀錄代替類別 (records over classes)、處理好副作用 ( taming side-effects )。我覺得 functional programming 有點像是人工智慧,聽起來有點酷、有點奇怪,但當你了解了它以後,就只是無聊、很平常的寫程式而已。

為什麼要函數化 ( functional )? 
因為軟體正在吃掉這個世界,它必須要做到最好。函數式編程已經被證明,比較少臭蟲 ( less bugs)、較不複雜 ( less complexity )、程式碼更可讀 ( more readable code ) 和更好的效能 ( more performance )。

物件導向程式設計 ( OOP ) 有什麼問題?
沒有問題,只是很難、常被誤用,而且有時是難以避免的。整個物件導向程式設計的模式 (paradigm) 是基於「送訊息給物件是唯一跟狀態 ( state ) 互動的方法」,因此狀態就會被分散。於是在分散式系統中狀態的一致的難度是跟世界和平一樣的 XD


物件導向程式設計 和 函數式編程的設計模式比較
Scott Wlaschin是很好的講者,不像我鼓勵大家去聽他的演講。

在 OOP 中,每次方法在某個實體上被呼叫其實就是副作用。副作用很難被追蹤、被理解,沒有人喜歡驚喜。驚喜在生活中是好的,但驚喜在程式碼裡面沒有任何好的地方。我們被教導要用繼承,但他是陷阱,程式碼會不夠彈性、很難之後改變。設計模式最難的是如何幫這些模式取名字,動詞偽裝成名詞。策略、工廠、Commands...

React 中最耀眼的原則是函式組成法 ( function composition )。

純函數 ( pure function ) vs 髒類別 (dirty class)

純函數沒有任何副作用。他很難去違反只負責一件事的原則 ( single responsibility principle) 因為純函數只有一個明顯的目的 --- 把輸入轉成輸出。所以測試就變得超簡單。

類別是髒的。互叫一個簡單的類別函式,就會改變它。誰做的?為什麼做?我們永遠不知道 ( 直到我們 debug 後)...

推薦這本 github 上的書適當的函數式編成指南 ( 在 github 上有 6000 顆星)


如果你不理解這個程式,沒關係。我也不懂。在函數式編程裡它等於 ( (4 + 0) * 2) + (4 * 2)
Immutable.js
不可變資料一旦被建立就不能被改變,這使得更簡單的應用程式開發,不用預防性的回傳複製品,更可以使用間單的邏輯來達到進階的 memoization 和改變偵測。一個針對不變資料的可變 API 並不改變原來資料,而是總是產生新的資料。
   - 和 原生的 Javascript array 有很相似的 API
   - 保持永遠的不可變 (List, stack, map, orderedMap, Set, OrderedSet and Record)
   - 非常快

---
PS:作者講的不多,上面很多都是照投影片上大量文字打的。

2015年11月7日 星期六

Redux = 事件驅動系統 = 伺服器

Redux 做的事情其實很簡單 ( 主程式才99行 ),就是可客制 Event 的 Event System。這概念在別的領域已經很成熟。但因為 Redux 的目標使用者是 Flux 的使用者,套用了很多原來 Flux 裡的專有名詞,所以對非 Flux 使用者變得很難懂。這邊透過類比大家都知道的名詞,目標讓 Redux 的概念連六歲小孩都能理解。

Flux:

Actions trigger reducer to update states in the store.


Redux 的行為等於事件驅動系統 ( Event-driven System ) / 有限狀態機 ( FSM ):

Events trigger event handler to update states in the machine.

Action Event | Signal | Message
Reducer Event Handler | Finite State Machine 中的 transducer


Redux 的行為等於一個網頁伺服器:

When a request came, using route table mapping to get a method to process it。

Action Http Request
Store.dispatch(Action) 送 Request 到 Server
Reducer Router 把 Request 送到對應的 Router Method,更新 Database
Store Database
UI / React Http Response


Redux的行為等於巷口那家... 哎 想不出來比較生活的說法。

現在有沒有覺得 Redux 很 Awesome?好像沒有啊... 但我們回到瀏覽器的環境重新看一下,因為 HTML 的元件很小,開發者會組合 HTML元件成為可重複使用的「大元件」。但問題是瀏覽器中的 「事件處理系統」 是針對 HTML 小元件的,沒有給「大元件」的。於是Redux 提供了給開發者可以自行定義事件的「大元件」事件處理系統,因為你可以控制整個事件處理系統,重播和紀錄事件都變成毫不費力的事。現在又感覺到  Redux 很 Awesome了吧!!!

故事到了這邊,一定會想這樣解說,哪個六歲小孩能了解啊,相信這是大家共同的疑惑,不過 「投資一定有風險,基金投資有賺有賠,申購前應詳閱公開說明書」,我會反省的...

---

延伸閱讀:
redux 的專有名詞解釋
Redux Issue 891:Is redux conflating actions with events?
六歲小孩也能懂的 Javascript Closure 說明