小確幸物語 之一

一陣沉睡 半夢半醒 

略見一縷陽光 輕灑

翻身 繼續盜夢 回到第三層

背酸 潛浮到第二層

眼縫 幸福還在身邊 沒醒 

再換個角度 掉落

時針 搖擺了幾下

好動的幸福 跑來跑去 跳上跳下

賢慧的幸福 曬完衣服 

但 還不想醒 因為 還不夠餓

週末 陽光 慵懶 徘徊 微妙 幸福

如何在北京辦理一年多簽

想在北京辦理一年多簽
很簡單,也很便宜
台灣旅行社代辦要價3k..真的是坑那些不懂人的錢
以下是最簡單的流程

===準備資料===
1.一張2吋照片
2.100 RMB
3.旅館開給你的居住證明
注意事項:
  a.必須在退房前就去辦理,否則機關人員無法在網路上
  查到相關資料
  b.給附印本即可,但要用A4印

===地點===
北京出入境管理局
(地鐵雍和宮站下車,出口B,然後順著馬路走約1km方可到達)

接下來就是當場填寫表格,然後抽號碼牌去繳交證件
最後到櫃檯繳費,工作日七日,扣掉假日大概是十天後可以拿到~

報告完畢!!

SCRUM的迷思

    軟件工程一直是個很有趣的領域，相關工程論從早期的CMMI、到近年流行(其實也不是近幾年，在台灣已經有聽到2005年就開始執行的專案)的敏捷(AGILE)開發，由於CMMI繁瑣的文件要求、瀑布式開發都讓人直覺認為執行一個專案最起碼要數月、半年、好幾年的時間，所以應運而生敏捷開發這個名詞，相關最著名的方法論為SCRUM，不小心這個方法個人帶的團隊有執行過；以下來探討一下人們對敏捷開發的迷思。
 
    再次強調，敏捷式開發不是軟工方法，敏捷只是一種心理狀態的描述、一種工作環境的意念，如果公司文化沒有敏捷的意圖或是想法存在，導入任何方法都沒有用。

    那SCRUM又是什麼，假如敏捷開發是個數學的應用問題，那SCRUM就是一套或許可以解決問題的公式，SCRUM只是一套方法、一種作業方式、一種運作模式、一種流程，SCRUM不是萬靈丹、SCRUM不是萬靈丹、SCRUM不是萬靈丹，因為很重要，所以要講三次。

迷思一：有了SCRUM就不用寫文件

    一言以蔽之：SCRUM是利用大量的溝通、許多的定期會議取代文件撰寫，所以在時程上並不會大量減少耗費人時，因為這是一種挖東牆補西牆的概念。但好處是因為溝通頻率高，各角色間的思考誤解會有效減少，避免各說各話。
    CMMI最令人詬病的就是那一拖拉庫的文件，從肥滋滋的客戶拿著錢需求來找你開始，一直到開發完成、測試完成，全部都是一連串的交付文件，包含每個月研發團隊開的會也要記錄，所以CMMI常常被罵到臭頭的都是這件事情。但用了SCRUM之後，難道就真的可以避開這些阿雜的事情嗎？
    CMMI設定的SA、SD、PG、Tester便缺少了文字依循，所以SCRUM放入了幾項元素：會議(快速、經常性的)、User Story。
    因應軟體開發這種腦力高度集中的產業，資訊需要快速交流、有效溝通，SCRUM的模型裡面針對溝通部分導入大量的會議，包含Daily standing meeting、Sprint retrospective meeting、DEMO meeting...
    所有的SCRUM教科書都說Daily standing meeting是一種每天要所有團隊成員以站立的方式開一個10 - 15分鐘的會，那這個會要幹什麼，一言以蔽之就是要資訊通透，會議中要求每個人只要說明前一天做了什麼、今天要做什麼、遇到什麼問題需要協助...

你真的以為會議都會在15分鐘內就結束嗎？

    除非你真是個非常有經驗Scrum Master相當會掌握會議僅度 or 技術能力很強可以理解每個成員想要表達的事情，一個理想的Daily standing meeting執行上其實不簡單，提供個人經驗分享。
    此外Retrospective meeting一定要把會議討論的重點跟調整方向記錄下來，口說無憑、時過境遷，很多事情不寫下來或是當下沒有決議，進度檢討流於空談。這種會議文件也不需要長篇大論，基本上就是一張A4就綽綽有餘，紀載會議時間、與會人員、決議事項、待辦事項(包含人、事、時)即可。

迷思二：SCRUM可以節省開發時程

北京紫禁城半日完程攻略

紫禁城一嶼

話說國共抗戰,國民黨退敗到台灣,
做了一件還不錯的大事,
就是把紫禁城裡的奇珍異寶都運送到了台灣
讓現在大陸人只能乖乖就範飛越台灣海峽到台灣故宮
但唯一搬不走的,就是那偌大宏偉的建築物

小時候唸地理常常講,大陸地大物博,物產豐富,
但自己的腳在沒有真的踏進這塊路地之前
我真的一直都抱著很懷疑的心態,
你們這些教科書編譯者應該都是在豪洨吧
一直來到了北京,我完全能體會什麼叫做"地大物博"了

所以想要半日逛完紫禁城(故宮)
老實說我會覺得有點難度,建議是可以花上一整天的時間
慢慢欣賞,風景可以細細拾蹈拾蹈,
以下是我建議的攻略

===購票消費===
1.長的像學生,或是看起來比較幼齒的,大膽的買學生票吧
跟全票差了三倍~
2.北京氣候乾燥,水分補給很重要,"進了宮"基本上要買水或食物
都很困難,就跟還珠格格想逃出來的難度差不多
所以麻煩先行購買,除非你很凱,可以被坑

===導覽===

北京街頭鬥牛全攻略

很幸運我住的小區就有個籃球場
而且距離不到20M(大心)

不過北京打籃球的人比想像中的還多
連故宮門外都有四五個球場!!
在北京打籃球其實跟台灣差異滿大的
大概可以從幾個面向來進行分析:

===場地===
1.北京風沙大,而且氣候乾燥,不管你的球顆粒再多,
想要有室內球場的手感相當難
2.很少有籃網的球框
3.高度標準,而且雙底線的距離明顯比台灣長

===技巧===
1.北京跳的高的人很少,可以幾乎說是沒有
所以他們卡位很扎實,比較嫩的人就會說這是比較髒
但我只說是卡位扎實,光靠卡位就能搶籃板
不過因為他們跳躍力普遍不佳,所以衝搶籃板變的很容易^^
2.回歸到氣候,因為風沙大,
他們出手的弧線也普遍偏低,但都很準,個個都是阿伯級的準度
3.運球很爛,沒有什麼護球,也看不到美式的cross over
4.上籃跟籃下進球率超高,應該都有75%,
在這邊籃下投不進壓力會很大,很丟臉...

===規則===
1.台灣三對三鬥牛洗球都在罰球線,他們則是要出三分線
但其實也沒有洗球的動作,反正就是球出了三分就開始算分
2.如果球是在底線出的球,要在底線發球
3.十分為一局,play隊數多的話則為五分

===隱藏規則===

軟體開發真的沒有銀彈嗎？淺談世界級軟體開源社群運作

圖片來源：One Piece

無人不知的軟體神書人月神話：軟體專案管理之道(The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition)其中一個章節提到人月神話這個迷思，簡單解釋，以工程學來說，今天我用50個人建一間房子需要100天，那工程上因為可以拆解工作，所以理論值(大量的平均數來看)可以用500個人在10天內建一間房子；這就是一種人月工時結構的估算。

很可惜，軟體並不是工程。軟體開發是一個很殘酷用智商高低決定勝負的領域，以開著同一款車，一個頂尖的賽車手頂多就比普通會開車的人快個2-3倍，但軟體頂尖程序員跟普通程序員可以差到百倍(the measure indicators should be include quality, scalability and stability)。

但今天透過網路無遠弗界的集結，開始有著一絲可以打破人月神話的運作機制存在，這個機制就是開發者社群(Community)。一個好的開放原始碼社群透過制度、標準、流程、規範有效集結世界各地志同道合的夥伴。以OpenStack開源社群為參考說明。

開源社群運作基礎流程：

1. 先有個code base，最小可能就只有幾千、幾萬行程式碼，然後由一個或兩個單位維護研發，eg：NASA, Rackspace。
2. source被open，並且License Agreement被擴張為Apache License，簡單的說就是拿到這個授權的程式碼，你可以無償的使用他，拿來改、賣都沒關係，隨便你搞，但前提是組織不負後續責任。通常這時候就會開始吸引到市場的鯊魚。
3. 忘了說，一定要有個源碼版控系統。
4. 社群建立，會開始進行幾件事情：
• 建置官方網站，繪製個吉祥物mascot感覺比較沒這麼枯燥乏味。
• 釋放Release Note(說明這個版本主要完成哪些功能)、發佈各種進程的版本(alpha, beta, candidate, stable, )、發布版本、定出版號、
• 針對社群貢獻者(contributors)會給幾條較有法律性的規範CLA(Contributors License Agreement)

2014末 - 自我技術成長的省思

最近悠悠轉轉某開源社群一段時間，鑽研其中一個主題，過程大概就是系統安裝、trace code、把架構搞清楚、拉哩拉雜用了一堆元件、再把python又複習了一下，腦袋中累積了不少東西，想把東西寫出來做個分享，表示自己好像獲得一項成就(?)，結果寫到一半，突然發現...

我現在不過是把社群上的英文文件翻成中文而已啊...

我現在不過是把社群上的英文文件翻成中文而已啊...

我現在不過是把社群上的英文文件翻成中文而已啊...

嚴重發現自己沒有貢獻(哪有人自己當穿新衣的國王，還同時扮演那個指著國王說沒有穿新衣的那個小孩)，不過就這樣一個move就得到一個反省思考的機會。

台灣的軟體實力長久以來，跟硬體、晶圓代工廠那些還可以跟世界搶單一較高下的技術來比，根本就是一塊如同殘障的領域。沒辦法，台灣一個小島才多少人，最強的都跑去當醫生、律師，再來是電機，然後才...好了，這種涉及到人身攻擊的議題到此為止。

關於軟體開源社群，在台灣能有"實質貢獻"的機會並不多；觀察幾年下來，台灣軟體產業界的毛病仍舊停滯不前。

1. 拿了國外寫好的開源專案，稍微改個UI、換個LOGO就說是新技術；這點其實很tricky，到底是拿既有開源專案去忽悠上面說開發了新技術，然後上面決策層級(擁有資源)的人很開心，就開始大肆做宣揚、媒體推廣的人但不去思考這到底算不算是一個真正能讓產業升級的關鍵技術。兩邊還真不知道誰對誰錯，也許這是一個共犯結構、上下交相賊，下面想辦法透過最短途徑讓長官開心，長官也有了新的題材讓大長官更開心，你開心、我開心、大家開心，開心之餘又有錢領何樂而不為，反正題材願景的泡泡只要不戳破就沒問題。
2. 不斷的做Me2

[OpenStack]如何修改OpenStack Horizon(Web UI)主題風格

本來這件事情，是不想當作一篇文章發佈，但在經過一個週末的休憩後，週一上班的時候就發現上周五的記憶就這樣蕩然無存...存在感跟螞蝗開出的633政見差不多低，所以趕快記一下...

如何修改OpenStack Horizon(Web UI)主題風格：

• OpenStack版本：Juno
• Vendor：Ubuntu
• 修改以下兩個檔案：
• Reference directory & file：/etc/openstack-dashboard/ubuntu_theme.py
• TEMPLATE_DIRS = ('/usr/share/openstack-dashboard-ubuntu-theme/templates', )

以上簡記

神註解 - 思考 Code Review 的重要性

無意間翻到一個放著發霉的js檔，傳說中是一間世界知名的硬體品牌廠對外網站產物，分享一下神註解(網路一夕爆紅，然後馬上就被撤)。

不要再跟我說code review不重要，你沒有時間做code review~

IDE混搭風 - 整合UltraEdit在Windows環境開發Linux系統

這是一個混搭的概念，適合用於一種特殊公司環境(絕大多數99.9%的幾萬名同事都活在Win系列)，而你自己也無法脫離(脫離了連收個信都很困難)的艱困環境下產生的IDE跨界混搭整合。

說明：

• 個人作業系統：Windows系列
• IDE：UltraEdit
• 程式語言：Python
• 研發運行環境：Linux系列
• Terminal：Putty
• 虛擬軟體：VirtualBox

配置：

• 開啟UltraEdit，點選檔案 -> 檔案檢視 -> FTP設定
• 設定要被遠端ssh連線的Ubuntu(執行在VirtualBox上)，輸入IP、帳號、密碼、預設登入目錄(defult是登入帳號的家目錄，但這樣不方便，因為你要開啟的目錄往往在其他地方)

研發主管職秘辛

圖片來源：http://s1.djyimg.com/

一些心得分享。

所謂團隊：自主運作、團隊產出與人力(數)成正比、隨時可以增添或拆解人力。
現在的團隊已經處於一個穩定狀態，透過兩週固定一次的例行會議，或是臨時性任務的E-Mail電子郵件交代，設定好人員、目標、時間，成員就能自行準時完成並且回報進度，以公司經營來說有點算是達成人力與目標的break even。雖說團隊規模還不大，但依照這樣的模式要擴大、因應新任務承接根本不成問題，並且依照人力的增補可以獲得相對應的工作產出，才是真正的團隊！這時候我就不需要注意細節部分的領導，可以把時間分配並專注於新領域的技術、市場導向研發。

個人領導原則：
個人其實在接下職務以前，早就對自己有所目標設定，兢兢業業不忘自己的領導原則。

自主型的團隊運作：
由於團隊是全新成立，為了讓大家及早進入狀況，採用敏捷式開發、每日站立會議方式提高成員間的溝通互動、大家對產品技術熟悉度。個人覺得強迫性導入敏捷的精神：時常溝通、不斷檢視是團隊現在能自主運作的最大成功因素，大家在需要的時候就迅速集合、快速討論、立刻下決定的處理方式，個人引以為傲。

除了滿足上級需求，更要培養菁英團隊：
一個主管的成功，如果只成功自己，個人不覺得是個成功領導。成功領導應是團隊性。怎麼培養真的是門藝術，要讓底下的人成長，成長到足以取代自己的位置，這樣自己才有基礎往更高的階梯上爬。
    至於如何滿足上級需求，這又是另一門學問了，簡單的說就是要用老闆的角度來思考事情，這裡不多述。

如何幫團隊擬定執行策略：
個人覺得這是件相當困難的事情，莫非定律表示：事情永遠在你很忙的時候，會冒出更多事情，所以幫團隊擬定最好的執行策略是當一個主管或領導最重要的任務：

1. 先找出最適合的人來負責事情，但要記得賦予權責：這裡講的是最適合，而非最好，大家都知道每個人專長都不一樣，有些人適合處理人際關係、有些人研發能力很強但可能文筆不是很好、有些人統御能力很強、有些人測試規劃很強，這些都是需要長期觀察並且試著去交辦任務才能發現，絕對不是把所有的事情往最強最厲害的人身上丟就沒事，那要你這個主管幹嘛？在強在厲害的人一天跟其他人一樣都只有24小時，主管要做的事就是去找出最適合的人選。找出人選後，要懂得授權，負責人有權利去調度人力或安排資源，不能讓他覺得綁手綁腳，最好也不要給其太多限制(除非觀念有所偏差，但這樣就不應該是你挑出來的人選)，讓成員有機會成長。
2. 給訂明確的目標

當Mac OS遇上VMware Workstation

謎之聲："個人喜歡Apple Inc.，也有iPhone、Mac Air...這篇純粹是秉著程序員求新的態度孕育而生~"

Apple Inc.在WWDC 2014橫空出世發表了新的programming language: Swift，以下是Apple自己給Swift的簡介：Swift is Apple's brand-new programming language for writing great iOS and OS X apps. Learn the basics of the language. See how to declare variables, use the fundamental data types, declare functions, and implement classes. Explore some of the great features that make Swift a safe, modern, and extremely powerful language. 簡單來說，Apple要將為人詬病已久不易上手的Object-C換到新語言Swift上，其支援近年流行的Lambda語法、Script隨寫隨編隨跑等特性，直教人想趕快玩一玩；但要用Swift可真是讓小弟費煞了一番苦心，沒有Mac怎麼辦？沒關係，Virtualization的第一名VMware真的很厲害~以下介紹如何在Windows上用VMware Workstation安裝Mac OS

個人測試環境需求：

1. VMware Workstaion 10 (以上)，才能支援最新版的Mac OS
2. VMware unlock tool (v120 以上)，得以解鎖Workstaion原本對Mac系列OS的屏蔽
3. Mac OS X Mountain Lion 10.8.3.iso or Mac OS X Mountain Lion 10.8.3.dmg
4. xcode6 beta.dmg

[VMWare Workstaion安裝Mac OS X步驟]

[OpenStack]使用DevStack快速部署OpenStack

OpenStack是一套雲計算 IaaS 的管理平台開源專案，相關的敘述不再多說，請自行上Google搜尋。鑑於陸陸續續聽到不少聲音說OpenStack相當難於建置部署，但發展至今，其實網路上的鄉民高手們已經提供很多強大的一鍵式安裝包，以下要介紹的是利用DevStack快速建置OpenStack。

個人部署環境說明：

• 虛擬化平台：VMware WorkStation 8 (免費的VirtualBox大家也相當推薦)
• OS：CentOS 6.5 64bits Eng.
• devstack Github：git clone git://github.com/openstack-dev/devstack.git
• 用VMware把CentOS 6.5裝起來，網路記得要打通，個人是用VM的虛擬網卡eth0 採bridge方式至手機的3G，在Virtual Network Editor選項可以對網路設定做修改
• 需要的指令，以藍字標註。

安裝步驟如下：

[建立OpenStack原始碼的下載目錄]

• 這裡先放在/tmp底下，請自行選擇
• $mkdir /tmp/devstack

[從Github拉最新的OpenStack原始碼]

• $cd /tmp/devstack
• $git clone https://github.com/openstack-dev/devstack.git