Art Pai

什麼是 UI，什麼是 UX？這種問題從索緒爾／結構主義語言學的角度來看是沒有（標準）答案的，因為詞彙與意義之間的對應關係不是因為詞彙與意義之間有個聯繫而產生，意義是因為詞彙在脈絡（context）之中的參照而產生的。換句話說，一個詞彙的意義只有看完句子的上下文，這個句子的上下句，甚至可能要看整篇文章，甚至收錄這篇文章的書，才可能產生。

但是沒有答案不代表這個問題沒有意義。會一直有人問這個問題，與大量「什麼是 UI / UX」 又彼此見解相異的文章代表了這個 UI / UX 的意義無法只透過一個句子的就產生出來，必須用到一整篇文章。既然意義還未確定，那表面上這些文章是在「解釋」UI / UX 的意思，但是實際上，這些文章是在「生產」UI / UX 的意思，甚至是在彼此競爭，看誰的定義能勝出。

網路上對於 UI 和 UX 的謬談 這篇文章收集了不少

那為什麼「解釋」UI / UX 文章這麼積極呢？我的觀察啦，這些文章的內容很少僅止於「什麼是 UI / UX」，大多數其實是在講 UI / UX design 是什麼，在說明 UI / UX design 要做什麼事，要會什麼。換句話說，這些文章的最終要服務的詞彙，是「 UI / UX designer」。像這篇標題「UX is not UI」但是內文寫「Here are the differences between the role of a UI designer and UX Designer」也不在少數。

所以，這些文章真正關心的是 UI / UX designer 的意義。與 UI / UX 不同，UI / UX designer 的意義開始牽涉到人對自己的認同，以及職稱會為自己代言的意義。如果我已經認同自己是 UI designer ，那 UI designer 的意思如果與視覺設計師差不多，或是跟只會畫 wireframe 的那位搞混，那可真是相當的困擾的。

以我自己來說呢，雖然最近寫 JavaScript 比 CSS 還多，但是離不開熱門 framework 的我要認同自己是個 front-end developer 還是沒辦法呢，覺得自己還是個 web designer。所以也因為這樣覺得 web designer 的意思是絕對不能把連 CSS 都不會寫的人都包進來的。

http://v4-alpha.getbootstrap.com/components/utilities/

經過一年的開發，Bootstrap V4 發佈了。UI 外觀上沒有什麼變化主要是程式碼的進步，引進新的技術 ———— 主要是 flexbox 和 ES6。

對於 flexbox ，bootstrap 文件是這樣說：

In a nutshell, flexbox provides simpler and more flexible layout options in CSS

所以，其實我對於有種說法「前端技術越來越難」，我的感覺是剛好相反的。

Class 的命名也有所進步，不再使用child selector，以前令人抓狂的 .nav > li > a 也都沒了。還以一個很棒的地方是 Utility classes 裡面多了一整套的 spacing style，像是

.m-a-0 { margin: 0 !important; } .m-t-0 { margin-top: 0 !important; } .m-r-0 { margin-right: 0 !important; } .m-b-0 { margin-bottom: 0 !important; } .m-l-0 { margin-left: 0 !important; } .m-x-0 { margin-right: 0 !important; margin-left: 0 !important; } .m-y-0 { margin-top: 0 !important; margin-bottom: 0 !important; }

當我以前說過我會寫這類的 helper style 來加速開發時（但是是有用到的才寫，不用寫全套），還被視為邪魔歪道呢。

投影片：Speakerdeck

這是我這次在 ModernWeb Conf 2015 的演講，嘗試用馬克思主義的角度來分享一點我工作一些年來的一些感想。這些感想是起源於現在台灣的勞動環境實在不佳，被稱為「鬼島」。但是為什麼我自己卻沒有別的勞動者遇到的問題呢？這當然不是因為我比較優秀，這點自覺我還是有的。

這是第一次在大型研討會演講，所以蠻緊張的，尤其是會議室居然坐滿了。結果很多本來想舉的例子沒有舉出來。像是在講「異化」的時候本來想講我從《不理性的力量》這本書看到的例子。《不理性的力量》裡面關於工作意義的實驗非常有趣，《不理性的力量》的作者丹教授設計了一個實驗：他隨機找志願者來做一份把樂高積木組裝起來的簡單工作並且給予酬勞，總共組裝10份。然後將志願者分AB組，A組是在組裝好後把成品很慎重的收起來，B組是志願者組裝好後立刻將成品打散，再請他重組一次。結果實驗下來，A組的志願者都表示工作很有意思有機會願意再做，B組表示這工作很爛，不高興。可見工作的「意義」是可以經過實驗證明的，不是哲學家的空談。

然後在講「工人與其生產行為的異化」時，也忘記講「專業分工」某種程度是這個層次的異化。我自己是覺得我有能力獨立完成一個網站，是讓我覺得網頁設計是一個整體而且對我是個有意義的工作。所以我對於「前後端都要寫」或是「設計兼前端」這種狀況不會有什麼不高興之處。還有在講「生產工具」的時候，也忘記講資訊自雇者跟傳統自雇工匠的不同之處，像是傳統工匠的產品敵不過工廠大量製造的競爭，但是資訊工作的成果本身已經是複製0成本，不會再被競爭了。另外資訊工作有開源文化，可以讓工作者互相學習，互相幫助，一起進步。不像傳統工匠的養成是師徒制，傳承不易，更難與工廠競爭。

ReactJS 用一陣子後，真是覺得越用越喜歡。現在還發現一個 ReactJS 的妙用，那就是建 Style Guide。我們都知道 CSS 也應該寫文件，最好寫得像 Bootstrap 的一樣方便好用。不過寫文件大家也知道是一件麻煩事，所以就有一些工具來幫忙。

一種工具是讓你在 CSS 上寫註解，然後再 parse 這個註解，像是你寫的 HTML 範例，幫你轉成文件。不過這個方式有個問題，就是在註解內寫文件還蠻痛苦的，。一來註解的顏色通常都比較淡，看得很辛苦。

再來就是 CSS 註解內，編輯器關於寫HTML的輔助功能都沒了。最大的問題是，萬一你網站template那邊的HTML+CSS要改，註解內的HTML範例你是要自己手動同步的，這個工具幫不上你。

最後一個問題就是自動轉出來的文件，HTML就是工具轉出來那樣了，要怎麼調整，我不會，而且成果也只是大致能接受而已，沒辦法隨心所欲的修改。

仔細想一下我需要工具幫我做的事情，最核心其實就是幫我把一段HTML code，要在文件頁上要看到「成果範例」以及「原始碼」方便對照以及 copy&paste 的。這不就是 ReactJS 剛好擅長的嗎？

比方說，我有一個 React Component 叫 Element，那我只要用 React.renderToStaticMarkup() 就可以秀出原始碼了。

詳細一點的gist

TonyQ 又開新戰場了。發源是抱怨拿到寫得很爛的CSS。

最厲害的就是 0 height 就算了，下一個區塊往上遞補的時候，不是回頭 clearfix ，竟然是補 margin-top 硬算。要這樣你怎麼不乾脆都用 position:absolute 算了，至少還不用在那邊玩俄羅斯方塊。

不然就是到處都把 width / height 寫死，明明可以倚賴父元素的寬度(100%)，硬要寫死是怎樣，而且從最外層 container 寫死到最內層（超過四層）。

之後開啟了對於自學CSS的討論。

只是該怎麼說呢，大概是前端完全都找不到什麼人教，所以我們也就習慣野外求生了。而設計至少設計專業還有人教，所以有些人也就只倚賴人教。

--TonyQ

自學努力的設計師非常多人，但寫出來的Html、Css 沒被認為邪魔歪道的有多少？我說希望找個指導者，是為了矯正錯誤糾正觀念，避免出現像你前文提到的那種「怎麼會這麼搞」

--Akane Lee

CSS能自學嗎？這邊所謂得自學CSS不只是學會語法，做出網頁而已。而是要滿足前端工程上的各種需求，能有彈性的適應變化。像是在template 要重複利用，文字長度可能不固定，甚至跟用戶互動等狀況。

我想了一下，要自學 好的CSS寫法 還真的想不到什麼資源。

請教一下 Even 有沒有地方學，Even 翻出了這本書 ： 無懈可擊的Web設計。不過問題是這本書2006，快10年前的，而且還是簡體書，會去買是真是超級有心。也就是說，並沒有一個比較普及的資源來教你這些事情。

Google 其實也幫不了你。要學好的JavaScript寫法你可以 Google "javascript design pattern" "maintainable javascript"，但是你找 "css design patter" 出來的結果是視覺上的pattern，找 "flexible css" 出來的 是關於 flexbox 規格（囧），找 "maintainable CSS" 出來的是 OOCSS, SMACSS, BEM 等整理 CSS code 的方法。

那「會寫 CSS 的人」到底是如何自學的？

我才不是什麼天生融合好的，我練了很久吃過各種錯誤，就跟你幹的設計師一樣，後來害死自己，做不下去，才認真把這些東西學好。

--Even Wu

簡單來講就是踩地雷，被炸幾次就知道要怎樣寫比較好了。靠踩雷來學的話，最好的方法還是自己的 CSS 自己維護了。寫出沒有彈性的 CSS 來搞到自己，下次才會想是不是換個寫法比較好。不過看起來 TonyQ 那邊的流程是設計師生出HTML/CSS交給 TonyQ 之後就不用理了，這樣怎麼會碰到的CSS造成的問題，然後透過解決問題來學習呢？

網頁設計師，是一種設計師。所謂設計，一個看起來最屌的說法就是設計是解決問題。設計是不是就是解決問題我不知道，不過我認為至少設計的「目的」是解決問題。

所以網頁設計師要有競爭力，就是要能解決網頁上的問題，才有競爭力。

有什麼問題呢？舉例一些，但是不只：

技術的問題

銀幕尺寸不確定

網路速度不夠快（永遠不夠快）

瀏覽器不確定

技術更新不等你

訪客的問題

訪客不一定是人（例如google bot）

訪客很懶惰，沒耐心（UX）

訪客隨時可以跑去別的網頁

美感的問題

不同的內容有不同適合的視覺設計

除了靜態的視覺效果，還有互動的動畫可以發揮

因為前陣子看到不少人大力的讚美 React.js ，所以我也忍不住也來玩玩看了。之前只知道 React.js 的特別之處在於 virtual dom，速度非常的快，但是速度不是我的興趣之處，所以就沒有再接觸了。這次再研究後才知道，React.js 還有一個特點就是能同時在 server side 以及 client side render，而且這個 virtual dom 的能力對於從server side render 出來的 HTML 也是有效的。

所以你可以讓 react.js 在 server render 好 HTML 後，再轉成用 javascript 來換頁，這就讓我非常有興趣了。以前 Twitter 曾經把頁面的 render 全部交給 JavaScript ，下場就是第一頁的render非常的慢。因為你要等JavaScript + template + json 全部抓完後，再用 JavaScript 把 HTML render出來，怎樣都沒有server直接吐 HTML給你快。看起來 react.js 可以解決這個問題。

我又再使用 http://bambooboard.net/ 當練習對象。因為1. 這是個討論板，是種內容網站，一定要有 server side 的 HTML 讓 google爬。2. 前後文章瀏覽，按讚以及有留言回應等互動的功能，基本要走 ajax ，UX 才會好。所以不能不用 JavaScript，但也不能連內容全用 JavaScript 來生成。 所以原本是採用文章內容會 render HTML，互動功能用angularJS 加上去的做法，換句話說是一個折衷方案，所以每次換文章都是比較慢的整頁 refresh，我一直希望能更快再快。

經過非常慘烈的學習與嘗試之後，終於成功換成 React.js 了，而且成果非常的好。現在你到 bambooboard 第一次會是收到 server render的 HTML，接下來連結到不同頁變成是用 ajax 拉 json 資料回來，大大增進速度與 UX。你也可以把 JavaScript 關掉，就是傳統的網站，每個文章都可以用連結到達，整個網站還是能運作的，只是每頁都要全頁 refresh 而已。這可是個沒話說的 progressive enhancement 實作啊。

從一個有理想（ progressive enhancement ）的 web designer 的角度來看，React.js 達成了其他 JavaScript framework/lib 都達不到的成果，已經值得推廣了。至於像是減少架構的複雜度之類的議題，因為我的程式很簡單，所以就比較不能評斷了。

AngularJS 團隊最近在 ng-europe 研討會上公佈了 AngularJS 2 的設計。原本只有投影片出來，有非常多的變更，讓很多人都嚇到了。尤其是 directive 的語法跟現在完全不一樣了。真的要升級的話，要改寫每個 directive… 應該是沒有人有時間吧。

不過看過影片後，因為每個更動在發表中都說明了理由，所以基本上每個更動都能接受了。其中 directive 的更動，也讓我又更了解 HTML 一點了。

以一個現在的 directive 寫法來對照：

<button ng-click="foo(bar)">×</button>

到 AngularJS 2 的版本會是：

<button (click)="foo(bar)">×</button>

我看到這個變更時，第一時間的反應是：「這也改太大了吧，而且 html attribute name 可以有括號嗎？這樣算是在寫 HTML 嗎？」後來我查了一下，在 stackoverflow 找到的答案：

http://stackoverflow.com/questions/925994/what-characters-are-allowed-in-an-html-attribute-name

原來對於 HTML5 的「parser spec」來說，括號是沒問題的。當然送 W3C 的 HTML validator 不會過，但是這點對於 ng-* 系列也是一樣的。

所以 AngularJS 2 的 directive 還是 HTML。

AngularJS 2 的 directive 語法解決了一個問題，就是從 HTML 這邊看不出這個 directive 是在接「值」還是「字面」進去。

現在如果我寫一個 directive 如下：

<tab name="myname" content="mycontent"></tab>

我可以在 directive 的 設定寫

scope: { name: '@', content: '=' }

這樣directive 這邊， scope.name 會接到的值是「字串」"myname" ，但是scope.content 接到的會是 mycontent 這個「變數」，兩個完全不一樣。但是在HTML上卻完全看不出來。

在 AngularJS 2 就是（應該）寫成

<tab name="myname" [content]="mycontent"></tab>

這樣區別很明顯，在 JavaScript 這邊不用再寫設定了。

其實 ReactJS 也有類似的概念，在 JSX 是寫成

<Tab name="myname" content={mycontent}></Tab>

在學 ReactJS時覺得這種區別相當不錯，所以對於 AngularJS 2 的改變我也覺得蠻好的了。

自柯文哲陣營推出了「野生官網」這個工程師玩具後，我就在想我能做什麼。基本上我對照片影片什麼的都沒什麼興趣，大概就覺得政見該好好看一下吧（是說我也不是台北市民為什麼要看...）所以就做了這個 UI 抄自 Reeder 的東西。

柯P新政閱讀器 http://minipai.github.io/kp-reader

其實也沒什麼功能，功能甚至比官方提供的API範例還少。要說的話就是看文章的時候網址會換！

遇到比較麻煩的是 API 回傳的政見不是照政見的編號排的，所以還要去抓標題中的編號重排，然後內文又重複寫了一次標題，在官網排版看起來很好，但是轉成單純的文字後看起來就很怪了，所以要砍掉。寫 regex 不是我的專長很麻煩啊啊。

也有做了 j k 換文章，但是遇到的問題是左方文章選單高度超出銀幕，還應該針對這個狀況做自動捲動，所以網站上就不說有這個功能了。

BambooBoard 是我沒事時用「討論區」當題目的練習作品。不過很意外的，最後居然做到我買個網址讓他上線了（上線本身也是練習）。這代表 VPS 也進步到能讓我也知道怎麼使用啦。

我一開始是用 Codeigniter 寫，Codeigniter 連 ORM 都沒有，所以花非常多時間在學 SQL，想怎麼撈資料，Post 和 Comment 的資料要用什麼方式聯繫起來，根本不太有辦法真正寫討論區的功能。後來 Rails 開始流行後，我也跟風去學了 Rails。比起 PHP，Ruby 真的是親切許多了，Rails 也讓我知道了 ORM 這種東西，搞懂 has_many 等資料之間的關係 ORM 就會幫我照顧好。因為要擔心的事情少了一個，用 Rails 終於寫得出一個雛形了。

後來因為 Rails 的 view 不能「繼承」，寫得有點苦，又聽到有人推 MongoDB + Express + AngularJS + node.js 這組「MEAN stack」，於是就再改用 MEAN stack 來練練看。放棄 Rails 改用 MEAN 之後，過去開發功能的阻礙都拿掉了。一是 Ruby，Ruby雖然相當好上手，但是畢竟平常沒在用，還是要一邊慢慢學，改成全部用 JavaScript 就沒這種問題了。二是RDBMS，關聯式資料庫的使用難度真是太高了，改用MongoDB後，不再需要 migrate db了，資料的擺放跟關聯方式也不用辛苦的想了。之後開發就很流暢，把討論區該有的功能都寫出來啦。

最後是上線。PHP最簡單，毫無困難。用 Rails 時是靠 Heroku，不過 Heroku 自己沒有提供 MongoDB，試著用 Heroku + MongoHQ 結果超慢。本來想放棄上線，但是後來看到 DigitalOcean 猛打的廣告，就去玩玩看。DigitalOcean可以直接開裝好 MEAN stack 的機器，網頁的界面也蠻友善的，DigitalOcean站內的 tutorial 又多，有我需要的，讓我也成功的讓程式跑在 server 上了。操作 VPS，這其實也是我以前不敢想的。

很高興看到這些討論！因為對於關心性／性別議題是文化素養的一部份，就跟專注公共議題是民主的基礎一樣。不過這些討論我發現一個很大的問題，就是一旦討論到性，話題幾乎都繞著「性別歧視」打轉。例如， yorkxin 一開始就斷定問題是有「女性歧視」到主辦單位回應可能有性別歧視之嫌然後又跳到RailsGirls可能有性別歧視以及 活動找ShowGirl 可能也是性別歧視。

用程式來比方，這還蠻像「什麼都想用 jQuery 解決」的。性別／性議題有很多種，不是只有性別歧視一種而已，只是性別歧視是最好理解的概念而已。就我看來，CoC 風波跟性別歧視沒有關係，Conf 上大螢幕跳出內衣廣告照片的錯誤，就只是違反 CoC 而已。 RubyConf 的 CoC 我覺得實在不是很具體，但是大致上來就是一個「去性化」的要求製造一個無性的空間，而這個無性空間的建構的「大義」就是要壓抑過去發生曾經過的性騷擾事件。為什麼內衣照片讓人很敏感的察覺到照片違反了 CoC ，就是因為內衣照片是包含性的內容，一個打破了原本純淨的「無性空間」的建構。所以這是性議題，不是性別議題。

而 RailsGirls 的規則，是可以以歧視為主題來討論。但是歧視的重點在檢討於「人」的權益是否受損？是否只因性別受到不公平的對待？而不是檢查「規則」有沒有字面上的公平。因為只看規則的話，你只是在做一個「政治正確」的檢查，議題就不在性別歧視上了。要討論人有沒有被歧視，你要一層一層的往上看所有的規則，包含社群的，社會的，國家的，文化的，意識形態的。要知道人會受到全部的規則影響，而不用寫的規則比寫出來的規則更有威力。就像要了解一個 JavaScript Object 的功能，要每層 prototype chain 都去看才行。不然你怎麼知道這層看起來是歧視男性的規則，是為了修正上一層優待男性的規則？

所以 RailsGirls 的規則如果是「女性限定」，我也認為沒有問題，因為大多數 coding 相關活動不用明文規則，就已經是「男性限定 」的環境，讓男性得以很自在的幾乎都是同性的環境交流。如果女性想要同樣的環境，那得再靠一條規則來扭轉。當然，政治正確也是一個很嚴肅的議題，我也認為我們應該再加強一下對於政治正確的接受度以及配合度，不要光是看到「徵人文字不得限制性別」就哇哇大叫。滿足政治正確很簡單，動一下腦筋能讓人滿意。有心的話，徵奶媽都可以不用寫出限女性的規則，RailsGrils 的規則也不例外。

現在前端開發的世界中，各種開發的「工具」也越來越受到重視了，也有很多文章，演講教你有哪些工具好用。有的常用工具我已經在用，可是有的沒辦法。

像是 Grunt 已經有名一陣子了，可是對我來說難度頗高，搞不清楚它是怎麼運作的，最多能複製別人寫好的範例而已。直到最近看到 Gulp 的投影片之後，看了 Gulp 的寫法覺得應該是在我能力範圍之內，所以就開始用實作來學習了。

跟 jQuery 一樣簡單

其實 Gulp 的語法還蠻直觀的，形式 jQuery 還蠻類似的，所以很好理解，也一樣透過 plugin 來讓各個動作串起來。

jQuery: 點擊一個按鈕要做一些事情

$('button').on('click', fucntion(){ $(this) .next() .addClass('fancy') .show() .cycle() })

Gulp: 定義一個工作要做一些事情

gulp.task('stylus', function() { gulp.src('./stylus/ng-trans.styl') .pipe(stylus()) .pipe(prefix("last 2 version", "> 1%", "ie 8")) .pipe(gulp.dest('./css')) });

以這段範例來說，在 command line 打 gulp stylus 就會幫你做 1. stylus 轉 css，2. css加上vendor-prefix，3. 存到指定目錄，3個動作，非常方便。因為 Gulp 本身還蠻簡單的，拿來換掉自己的小專案的 Grunt 時，一下子就搞定了。所以我主觀認定 Gulp 也跟 jQuery 一樣，是設計師工具了。

不過在引進到公司網站時，因為規模比較大，要做的事情比較多，所以很多要做的事情都研究（google）了好一陣子才解決。不過這不是 Gulp 的問題，而是 Gulp 還年輕，Gulp 的 plugin 數量也比較少，沒那麼成熟。例如我就遇到 plugin 提供的 option 不足（看看jquery cycle 的可以設定 option），要自己修改 source。還有就是教學與範例比較少，研究（google）起來比較辛苦。

Gulp 的使用方式與介紹也蠻多的了，這邊就不再多說了。

Gulp 使用後

在實際用了 Gulp 之後，發現這個好用工具不只是方便，更讓自己對開發流程的掌控又更進了一步，這是在開始學之前沒有想到過的。

原本，公司網站的 Stylus/CoffeeScript 是用 supervisord(python) 執行 stylus cli 和 coffee cli，CSS 和 JavaScript 的合併和壓縮是 webassets(python) 來處理，分散在不同地方。這等於是把管理前端檔案的工作交給後端同事，增加了別人的工作，自己也沒辦法調整流程讓自己工作更順暢。

其實我也一直覺得 webassets(python) 的功能不怎麼樣，不像 Rails 對前端檔案的管理相當完整，xdite 有一個演講（為什麼你還是應該使用Rails 開發：前端加速以及前端開發管理）在講這件事。不過用了 Gulp 之後，前端檔案的管理也不需要靠後端 framework 的支援了。Stylus/CoffeeScript的編譯、合併、壓縮以及加 hash 等等工作都能交給 Gulp 完成。

其實之前看到 Stylus 出來後，就還蠻想嘗試看看了。只是說 Stylus 和 Scss 的功能差異不像當初 LESS 和 Scss 的差異那麼大， Scss 已經用習慣了以後，要跳槽還真需要一點額外的動力。

在過年前幾年，工作夥伴提到開發環境裡 Sass 是唯一要用到 Ruby 的因素，要是沒有就好了。再加上 Sass compile 的速度還真是慢，我每次都要微等一下再 reload browser 才能看到結果。所以合起來就有充分的動力來換了。

然後公司網站也沒有用 Compass，要轉換的阻力就小很多了。於是我就利用今年過年有空的時候，把公司的 Scss 轉成 Stylus。 本來以為會很快，幾個 search & replace 就好了，沒想到枝節還蠻多的，再加上一些 Stylus 的錯誤訊息真是不知道在表達什麼，試很久才知道問題在哪裡。不過看不懂的錯誤訊息我覺得在直接寫 Stylus 時應該不會發生，所以才沒有被處理到。

Stylus 的 variable interpolation （用 {} 包起來）也比較弱，只支援在 selector 裡面使用，像是

-webkit-{prop} : args -moz-{prop} : args {prop} : args

在其他地方就要改用最一般的字串相加（ + ）了。

還有一些小差異不會報錯，要自己看CSS的diff 抓出來。像是原本 Scss 的變數是用 $color: #fff 來表示，Stylus 是比較像程式語言的 color = #fff ，但是 Scss 的表示方式在 Stylus 也不是錯誤，而是當作普通的樣式直接放過去。

在轉成 Stylus 之後，我也順便引進了 Autoprefixer 幫我自動加 vendor prefix，這也是我聽到很久一直想用的東西。也再次令人感到前端的進步速度真的很快，前不久用 Compass 來幫忙處理 vendor prefix 還很潮，現在一下就過時了，改用 postprocessor 來處理會更好。

本來看到這篇 Web Standards Killed the HTML Star 時，不覺得內容有什麼特別，5年前我也是只要在blog上寫幾篇 IE6 的 CSS hack 經驗就很好找（只要會寫CSS就好）工作，現在應該已經沒這種好事了。

今天看到朋友討論 Git ，發現我用的 GUI - Gitbox 還真是不怎麼有名。所以來寫一點介紹推薦一下。為什麼我要使用以及推薦 Gitbox呢？最重要的原因是在 Gitbox 的界面之下，Git 的概念一點都不困難。

有朋友表示「實際去教人，有的人連add/commit/push 都搞不清楚在幹嘛」。其實我也是覺得 add/commit/push 的概念在CLI下非常抽象，但是在 Gitbox的畫面下就很清楚了：

中間的欄位是一個「歷史記錄」，右邊欄位裡面的檔案則是全部有更動的檔案。因為是全新的資料夾，所以兩個檔案都是新檔案（new file）。在 Git 你要選擇你要「加（add）」哪些更動到這次的「提交（commit）」，而不一定要提交全部的更動。例如這次我就只想要 commit 新增了README而已，我只要簡單打勾，然後寫個訊息：

然後，按下「commit」我們就多了一個 commit 記錄了：

簡單吧，就算你不知道 git add 是什麼鬼，打勾的東西才會存進去是看得懂的吧。

如果你不知道為什麼要 commit 的話，這邊有一個例子。我覺得新增README不是我要的 ，我就在「歷史記錄」的 init commit 上右鍵， 執行 reset branch ，意思就是把歷史倒退到這個 commit 上。結果就變成這樣：

哇！之前的修改通通不見了。這就是做設計用 Git 的好處，你東西寫錯了，可以反悔回到前幾步。

Git 比起單純的 history，最大的差別就是 Git 不只有一條線，Git 有 branch/merge/rebase 的能力。要用這些功能在 Gitbox 也很簡單。

要branch很簡單，就在下拉選單上而已。我們來做一個叫 prototype 的 branch，然後做一些事情：

在prototype上的事情做完以後，我們再到 master branch 上做一點事情，畫面會像這樣：

在上方 master ( merge) prototype 的意思是你在比較兩個 master 和 prototype 這兩個branch 的差異，中間的 merge 是你可以執行的動作。在 history 裡面...

綠色圓點代表左邊（也就是工作中）的 branch（master）上存在的 但是不存在右邊的branch（prototype） 上的 commit。

藍色圓點代表右邊的 branch上存在的，但是不存在左邊（也就是工作中）的 branch 上的 commit。

我想要把 prototype 上的 commit 「融合（merge）」到 master 上，只要按中間那個按鈕就行了，相信你看到UI畫面也早就知道了。看，藍色圓點消失了，多了一個 commit。

如果你按下 command + shift，merge 會變成rebase，那結果又不一樣了。

在藍綠色點的對比之下，branch/merge/rebase 也不是很難懂的觀念了吧。我個人是覺得比其他 Git GUI裡會看到的「鐵道圖」還好理解。

在 SourceTree，fetch/pull/push/branch/merge 都在 toolbar上，在我看來這是很爛的UI，完全沒有經過設計。

但是在 Gitbox 就不一樣了：

你能做什麼事情，一目瞭然。雖然Gitbox 的UI一個圖示都沒有，但是在UX上可以說是大勝其他 Git GUI。

在 Gitbox 的幫助下，我在使用 Git 上是相當愉快而沒有感覺什麼難度的。雖然老實說我沒有真的很深入了解到 Git 的精華，就像使用 jQuery 而沒有很了解 JavaScript。但是在與 developer 的團隊合作上已經沒有什麼問題了。所以如果你真的搞不懂 Git 的話，我推薦你先用 Gitbox 看看。

同性戀能不能結婚——這場價值觀的戰役在2013年11月30號在護家陣營上街頭後來到最高潮。兩方的價值觀本幾乎沒有相容的可能，也幾乎沒有溝通的空間。比方說，我看到最經典的對話大意是這樣的：

「今天同性可以結婚，是不是改天嫖妓也可以，吸毒也沒關係？」 「性交易除罪化很好，吸毒在先進國家也」

到後來我也沒看到什麼人在進行溝通了，比方說我看到支持同性婚姻的人最常做的事情就是拿出反對方許多較為失控而很明顯無理的言論進行強力的批判甚至是諷刺。

不過，雖然兩方的價值觀來說是沒有調和的可能（同性「可以」和「不可以」結婚中間沒有模糊空間），但是訂定一個兩邊都能接受的婚姻法制是有可能的。

首先來看支持同性婚姻的核心理由「反歧視」。

先離題講一下「歧視」吧。不知道這個莫名其妙的翻譯是怎麼來的，導致很多人的誤會。因為歧視的意思是「針對特定族群的成員，僅僅由於其身份或歸類而給予較差的對待」。重點是「對待」而非你怎麼看某個人，跟「視」一點關係都沒有，跟你怎麼看對方一點關係都沒有。換句話說，你覺得同性戀很噁心，但是不反對同性戀也能結婚，你就沒有歧視同性戀。但是相反的，如果你覺得同性戀很平常，但是卻反對同性戀能結婚，你就是歧視同性戀。不過很多人從字面錯誤的解讀「歧視」這個詞，以為歧視的行為是指前者，就大聲說自己沒有歧視同性戀了。

歧視的罪惡在於身份或歸類是無法改變或是很難改變的，但是「行為」不是，行為是個人的選擇，因此我們可以訂立法律處罰某些「行為」。這沒有歧視任何人，因為這些行為是每個人能選擇做與不做。你也可以根據個人的「能力」來給予某個人獎勵或是資格，因為大部份的能力都是能鍛鍊的。

所以基於不能性別歧視的原則，你不能在徵人時限制應徵者是男性女性，只能針對能力進行篩選。最簡單的例子是如果你有搬運重物的需求，你不能因為男性通常力氣較大，就直接寫「徵男性」，而是應該寫「需能抬起大於100公斤重物」。同樣的原則，在法律裡直接寫婚姻只能由「男女」進行當然是有歧視的，因為你直接將性別這個先天的身份寫到法律裡面了，所以我們必須將婚姻改成「雙方」。

在滿足贊成方的要求後，接下來我們來滿足反對方的要求。在這邊以基督徒的理由當作代表，因為反對的理由很多種，但是其中只有基督徒比較知道自己在為什麼反對。最少，要以文化傳統來作為反對理由的話，基督教的文化傳統確實是一夫一妻的。

基督徒的對於婚姻的期待無外乎「生育」跟「性忠貞」，因此基督徒在反對同性婚姻的理由常見「異性能生育，同性不行」「今天開放同性婚姻，恐怕明天就開放嫖妓，後天全面性解放」。

同性戀不能生育是反對同性婚姻的一大理由。生育是一種行為，所以我們可以對行為進行法律規範而不算歧視。我們可以禁止夫妻結婚卻不生育，這也是會同時影響到異性戀夫妻，技術上不算針對同性戀。

幸運的是， 我同時也觀察到基督徒對於「法律禁止」的滿足條件是非常低的，因為對於基督徒來說性是非常神聖的，只能發生在夫妻之間，所以婚前性行為不可以，性交易當然也不可以。雖然說性交易算是法律所不允許，但是性交易只是個在社會秩序維護法處三萬元以下「罰緩」的輕罪，但是沒有基督教團體對此進行抗議，所以說這樣程度的規定與罰緩，就算是有「禁止」了。我個人也在特地在臉書上詢問一位基督教朋友的看法，他也沒有對此表達什麼不滿。